Artificial Intelligence & Machine Learning , Black Hat , Events
MLOps Platforms: Why Models Should Be Treated as Code
JFrog's Shachar Menashe on MLOps Platform Vulnerabilities and Code Execution RisksAs organizations increasingly integrate machine learning models into their systems, machine learning operations, or MLOps, platforms are becoming an attractive target for attackers due to inherent and implementation vulnerabilities.
See Also: Corelight's Brian Dye on NDR's Role in Defeating Ransomware
Certain types of machine learning models have code execution as a feature. Developers can insert codes into these models, and loading the model executes the code. "This can be used in various exploitation scenarios, including client-side attacks, server-side attacks," said Shachar Menashe, senior director of security research at JFrog. "Because it's vulnerability in the format type, there's never going to be a CVE about this, because there's nothing to fix. That's why you need to treat [machine learning] models as code."
Security practitioners also grapple with the unsandboxed execution of JavaScript within Jupyter Notebooks, Menashe said. "What that means is: If you're running some code snippet and - accidentally - it generates JavaScript, then it has access to the whole environment and the Jupyter environment," he said. "Every XSS attack, when it's done in a Jupyter environment, becomes remote code execution."
Menashe advised disabling unused features in MLOps platforms, ensuring that any models used do not allow code execution, and adopting tools such as plug-ins for Jupyter Notebooks to mitigate XSS risks.
In this video interview with Information Security Media Group at Black Hat 2024, Menashe also discussed:
- Container breakout vulnerabilities in MLOps platforms;
- The lack of built-in authentication in many MLOps solutions;
- JFrog's research on the security and attack surface of MLOps.
Menashe leads the security research division at JFrog, specializing in automated vulnerability research techniques. He has more than 15 years of experience in security research and engineering, including low-level R&D, reverse engineering and vulnerability research.