nttoole
commented
3 months ago After some evalution (pun unintended), the telemetry equation field needs to be flexible enough to support simple arithmetic, built-in math library, as well as user-defined functions. Safer alternatives appear either too restrictive or require substantial configuration setup to be able to support existing functionality. Since the threat comes from project-maintained config files, our recommendation is for projects to ensure those files and directories are secured appropriately to help mitigate risk.
Similarly, the wait() risk involves controlling the codebase, which means a security risk has already been exploited.
As such, we will be marking this issue as wont-fix.
Multiple Local Code Executions (using eval)
AIT-Core is a highly customisable framework that allows its users to employ Python expressions in some regions of its functionality. However, in some cases, the framework uses the eval function, which is inherently insecure, to evaluate the Python code. The most impactful occurrences of those calls have been found in the API wait function ait/core/api.py (see Figure 6) and ait/core/tlm.py (see Figure 7) files.
Figure 6: eval occurrence in the API
Figure 7: eval occurrence in TLM packet expression.
API
AIT-Core provides an API wait function that waits either for a specified number of seconds or for a given condition to be True. The conditions may take several forms: Python string expression, lambda, or function. Regardless of the chosen form, they are passed as a string to the wait function, which evaluates that string using eval. Although this functionality is handy, it is prone to the Local Code Execution vulnerability, which is also very easy to exploit.
Figure 8: Call the wait function with a Python payload.
Figure 8 shows an example of a malicious Python expression, while Figure 9 demonstrates the execution of that payload to achieve the Local Code Execution.
Figure 9: Code Execution via wait API function.
TLM
Similarly to the API, TLM allows for the evaluation of Packet Expressions, which can also be Python code. The actual expression is provided in the Packet definition and evaluated every time it is called. To exploit this vulnerability, it is first necessary to modify the packet definition by including the malicious expression, which will be executed every time AIT-Core references that updated attribute.
Figure 10: An example of a malicious packet expression.
Figure 10 shows an example of a malicious packet expression, which, in this case, imports the os Python module and executes a system command. Figure 11 presents an example of how and when this expression will be evaluated. First, the packet definition is loaded into the TLM module (line 3). The packet is created (lines 4 and 5), and the attribute containing the malicious expression is called within the print function, thereby evaluating this malicious expression (line 7).
Figure 11: Test case to demonstrate the Local Code Execution.
Figure 12 demonstrates the execution of the above test case, showing how the earlier expression allows for achieving the Local Code Execution.
Figure 12: Demonstration of Local Code Execution via TLM Packet Expression.
Recommendations
Although the Python eval function is handy, it is inherently insecure. We recommend using third-party libraries that provide the same functionality but sanitise the input to handle expression evaluation securely.