Associative Execution enables mapping each application to the processes allowed to run it
Application Control (Allow Lists)
Karamba Security XGuard’s device hardening includes an allow-list enforcement component that protects the device against dropped malware that may be used for remote code execution, and against the execution of files that have been tampered with. OS and application files, shared objects (libraries), scripts, and Kernel objects are all checked against the XGuard Allow List.
Each time any binary is loaded to be executed, its unique signature is calculated, based on the content of the file, and compared to a list of approved application signatures and constraints. If a binary’s signature is not on the Allow List, it is not a legitimate component originating within the device’s trusted settings. As soon as malicious or tampered code attempts to be loaded to memory, the binary is stopped from loading, and an alert is sent to the security administrator, or logged on the device, as configured.
Associative Execution Control
Beyond the basic Allow List, XGuard can also be used to prevent unauthorized processes from running otherwise “allowed” applications. The Associative Execution configuration file limits the execution scope for each of the allowed executable to one or more defined “launcher” processes (i.e., executables) that are permitted to run it.
Any process that will try to run such a protected executable, but is not associated with it via this mapping, will be blocked from doing so.
This mechanism protects the device not only from dropper (unknown launcher) attacks but also from legitimate programs on the device that do not need these specified processes, so that a possible vulnerability in the code cannot be used to launch the process from native code by altering logic in some way.
Examples of Allow-List and Associative Execution Protection
As illustrated in the diagram:
- The mal_code and hack_try executables would be blocked before running because they are not on the Allow List at all; they were not included in the original factory-released device, so must have been “dropped” during runtime.
- legit_a is on the Allow List, but at the time an attempt is made to run it, the executable will be blocked because it has been modified and its identifying hash no longer matches that of the original file.
- iptables, grep, power_off, and the other executables in the diagram all match the Allow List, but in the Associative Execution configuration file, each of the first three is listed with a defined set of programs that are permitted to run it. As a result, the launching of those executables in any other cases (represented by the three arcs) will be blocked.
Generation & Securing of the Allow-List Policy
Karamba’s technology creates policy files containing SHA256 hashes of allowed executables, to be used by validation code during runtime. Binaries (i.e., all executables, libraries, kernel modules and scripts in the image) are automatically scanned, and hash values are generated. The allow-list data is secured via an RSA cryptographic key-pair.
Policy signing is done either locally or remotely via a dedicated signing server. There’s also an option to integrate with customer’s key infrastructure to obtain the key pair. Additional policy files may be added after the main build, including those allowing third-party software.
Read more about XGuard and the types of attacks addressed by the XGuard Suite, and access related white papers, on the product page.
