CVE-2024-3660

What it actually does

A code injection vulnerability in TensorFlow's Keras framework allows for arbitrary code execution. When an application using a vulnerable version of Keras loads a specially crafted machine learning model, the embedded malicious code is executed with the full permissions of the application process. This provides an attacker with a direct method to achieve remote code execution (RCE) on the host system.

Why it matters to the business

This critical vulnerability allows an attacker to completely compromise the server running the machine learning application. This can lead to the theft of sensitive data, including intellectual property like model weights and training data, disruption of critical services, and unauthorized access to the wider corporate network. The high CVSS score of 9.8 reflects the ease of exploitation and the total loss of confidentiality, integrity, and availability.

How an attack unfolds

An attacker first creates a malicious machine learning model containing a payload designed to execute code. They then distribute this model, for example, by publishing it to a public model repository, tricking a developer into using it via social engineering, or compromising a legitimate model in a supply chain attack. When a victim's application, using a vulnerable version of Keras, loads this malicious model, the vulnerability is triggered, and the attacker's code runs on the server, achieving full system compromise.

How to fix it

Upgrade the Keras library to a patched version. The vulnerability is fixed in Keras 2.13 and later. For projects using TensorFlow, ensure you are using a version that bundles a non-vulnerable version of Keras. The specific fix was introduced in commit `b3ffea6602dbbb481e82312baa24fe657de83e11`. As a mitigation, strictly control the sources of machine learning models and only load models from trusted, verified origins. Consider running model inference workloads in sandboxed or containerized environments with minimal privileges.

How to confirm the fix worked

To confirm remediation, verify that all applications and environments are using Keras version 2.13 or newer. This can be done by checking the dependency manifests (e.g., `requirements.txt`, `Pipfile.lock`) of your Python projects. You can also programmatically check the version at runtime with `import keras; print(keras.__version__)`. Scan your software bill of materials (SBOM) to ensure no vulnerable instances of Keras remain in your software supply chain.

Typical attack path

1. The attacker crafts a malicious machine learning model file containing an arbitrary code execution payload.
2. The attacker makes the malicious model available to the target, for instance, by uploading it to a public repository or through social engineering.
3. The victim's application, which uses a vulnerable version of the Keras library, loads the malicious model.
4. During the model loading and parsing process, the vulnerable code in Keras executes the attacker's payload.
5. The attacker gains remote code execution on the server with the privileges of the application, allowing them to steal data, install malware, or pivot to other systems.

How to detect it

To detect potential exploitation, monitor for anomalous behavior from application processes that use Keras/TensorFlow. Look for these processes spawning unexpected child processes (e.g., shells like `sh` or `powershell`), making outbound network connections to unusual destinations, or accessing sensitive files or directories. Analyze application and system logs (e.g., auditd, Sysmon) for these indicators. Also, monitor the sources of models being loaded; a model loaded from an untrusted URL or file path could be an indicator of an attempt.

What your security team should do

• Immediately identify all applications using TensorFlow or the standalone Keras library and upgrade any instances using a version prior to 2.13.
• Implement a strict policy for ML model provenance, ensuring that all models loaded into production systems are from trusted, internally-vetted sources.
• Isolate workloads that process external or untrusted models in sandboxed environments with restricted permissions and network access to limit the potential impact of a compromise.