Remote Code Execution in AWS SageMaker Python SDK via Unsafe eval()

The AWS SageMaker Python SDK facilitates the interaction with SageMaker services, including the 'JumpStart' feature which provides pre-trained models and solution templates. The vulnerability is located in the sagemaker.core.jumpstart.search module, which handles the logic for filtering and searching through these models.

The specific flaw lies in how the SDK processes search expressions. When a user (or an upstream application) provides a search query, the SDK parses this query to filter the available models. Prior to version 3.4.0, this parsing logic relied on dynamically constructing a Python string representing the boolean logic of the search and executing it using the built-in eval() function. This creates a classic 'Eval Injection' scenario (CWE-95), where untrusted data is treated as code.

The root cause is the insecure implementation of the _Filter class in sagemaker-core/src/sagemaker/core/jumpstart/search.py. The match method in this class was responsible for determining if a model's keywords matched a user's search query. To achieve this, it performed the following steps:

1. Expression Conversion: It converted the search query into a Python-compatible boolean expression string. For example, a query for task:image_classification might be converted into a string resembling any(k == 'image_classification' for k in keywords).
2. Dynamic Execution: It passed this generated string to eval().

While the developers attempted to sandbox the execution by passing an empty dictionary for __builtins__ (eval(expr, {"__builtins__": {}}, ...)), this is a well-documented anti-pattern in Python security. In Python, restricting __builtins__ is insufficient to prevent code execution because the runtime's introspection capabilities allow an attacker to recover the object hierarchy. An attacker can access the __class__ attribute of any object, traverse up to object, and then list __subclasses__() to find classes that provide access to global scope or dangerous modules like os or subprocess.

The remediation strategy involved a complete rewrite of the filtering logic, moving from dynamic evaluation to a static parsing approach. The following comparison highlights the critical changes.

Vulnerable Implementation (< 3.4.0) The vulnerable code relied on eval to process logic. The sandbox attempt is visible in the second argument to eval.

# sagemaker/core/jumpstart/search.py (Vulnerable)
 
def match(self, keywords: List[str]) -> bool:
    # expr is a string constructed from user input
    expr: str = self._convert_expression(self.expression)
    try:
        # DANGER: Executing the string as code
        return eval(expr, {"__builtins__": {}}, {"keywords": keywords, "any": any})
    except Exception:
        return False

Patched Implementation (v3.4.0) The fix replaces eval with a robust tokenizer and parser. The _Filter class now generates an Abstract Syntax Tree (AST) composed of safe node types (_AndNode, _OrNode, _PatternNode).

# sagemaker/core/jumpstart/search.py (Patched)
 
def match(self, keywords: List[str]) -> bool:
    try:
        # SAFE: Parsing logic into an AST structure
        ast_tree = self._parse_expression(self.expression)
        # Evaluating the AST requires no dynamic code execution
        return ast_tree.evaluate(keywords)
    except Exception:
        return False

The new implementation explicitly defines valid operations. For example, the _PatternNode only supports specific string matching logic (startswith, endswith, in, ==), eliminating the possibility of executing arbitrary function calls.

To exploit this vulnerability, an attacker must control the query string passed to the search_hub() function. While the sagemaker SDK is often used in authenticated, client-side scripts (lowering the risk), it is also frequently integrated into backend services or ML platforms that expose search functionality to end-users.

Attack Scenario

1. Injection: The attacker inputs a crafted string designed to break out of the boolean logic structure. A payload might look like: "a") and [c for c in ().__class__.__base__.__subclasses__() if c.__name__ == 'BuiltinImporter'][0]().load_module('os').system('id') #.
2. Sandbox Escape: The payload uses Python introspection:
   • ().__class__.__base__ accesses the base object class.
   • __subclasses__() lists all available classes in the current runtime.
   • The attacker iterates through this list to find a class that allows module loading (e.g., BuiltinImporter or catch_warnings).
3. Execution: Once a handle to os or subprocess is obtained, the attacker executes arbitrary system commands. Since the eval happens within the application's process, the commands run with the same privileges as the application.

The impact of this vulnerability is rated High (CVSS 8.5). Successful exploitation results in full Remote Code Execution (RCE) within the context of the application using the SDK.

• Confidentiality: An attacker can read sensitive data from the environment, including AWS credentials (IAM roles, Access Keys) often present in the environment variables of SageMaker jobs or local development machines.
• Integrity: Attackers can modify data, inject malicious models, or tamper with the training pipeline.
• Availability: Attackers can crash the application or use the compute resources for cryptomining.

The vector is assessed as Local (AV:L) because the vulnerability is in a library. The attacker does not exploit the library directly over the network but rather exploits the application that uses the library to process remote input. However, if the application exposes this search feature via a web API, the effective attack vector becomes network-based.