MID-014: Sandboxing
Mitigation Tier: Intermediate
Description
Sandboxes are software execution environments that run code under restrictions to limit that code’s access to system resources a non-restricted user-level process would otherwise have access to. This is especially useful when handling untrusted code provided by users (e.g., a PLC program) or 3rd parties (e.g., JavaScript from a remote web site), especially when supporting such code is a mandatory device function and cannot simply be forbidden (as in MID-051).
A sandbox runtime provides only filtered and managed access to system resources. For example, an untrusted program will not have direct access to invoke kernel syscalls, read or write to files, access network interfaces, etc. The runtime can then provide only limited access to specific constrained resources governed by security policy, which can significantly reduce the risk of executing untrusted code. These protections will make lateral movement to different processes more difficult for malicious code running within a sandbox, as the code has no access to memory in those processes and has very little, to no, access to privileged function calls. Malicious code will be unable to access and manipulate data, memory, and code outside the sandbox without first finding and exploiting a vulnerability in the sandbox itself. Mobile devices running iOS and Android are a widely used example of this, running all applications in individual sandboxes to protect user data from malicious applications [1][4]. Another example is the WebAssembly format, adopted recently in web browsers, which allows compiled code to safely execute in a sandbox created by the browser (similar to how JavaScript code is sandboxed) [5].
Additionally, the abstraction provided by a sandbox can be used to prevent untrusted code from exploiting vulnerabilities that require low-level access to hardware (e.g., TID-103, TID-110). For example, in response to the Spectre and Meltdown vulnerabilities, web browsers deployed changes to their JavaScript engines to reduce the resolution of timers available to JavaScript code, reducing timer accuracy below the threshold necessary to successfully exploit the timing-based side channel [2][3]. A similar change in Chromium-based browsers eliminates a form of RowHammer that researchers crafted using JavaScript and WebGL [2].
IEC 62443 4-2 Mappings
- SAR / EDR / HDR / NDR 3.2 – Protection from malicious code
References
[1] Apple. “Apple Platform Security.” apple.com. Accessed: Aug. 26, 2024. [Online]. Available: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf
[2] The Chromium Projects. “Mitigating Side-Channel Attacks.” Chromium Security. Accessed: Sep. 5, 2024. [Online.] Available: https://www.chromium.org/Home/chromium-security/ssca/
[3] L. Wagner. “Mitigations landing for new class of timing attack.” Mozilla Security Blog. Accessed: Sep. 5, 2024. [Online.] Available: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
[4] Android Open Source Project. “Application Sandbox.” AOSP Documentation. Accessed: Sep. 10, 2024. [Online.] Available: https://source.android.com/docs/security/app-sandbox
[5] WebAssembly. “Security.” webassembly.org. Accessed: Sep. 10, 2024. [Online.] Available: https://webassembly.org/docs/security/