A group of researchers from the Free University of Amsterdam revealed via a blog post a tool called "casper" which highlight that it is designed to identify code snippets in the Linux kernel that can be used to exploit Specter class vulnerabilities caused by speculative code execution by the processor.
For those who are unaware of this type of attack, they should know that class vulnerabilities such as Specter v1 allow to determine the contents of memory, a certain script (gadgets) is required in privileged code, leading to speculative execution of instructions.
To optimize, the processor starts running such devices in a speculative modeor, then determines that the branch prediction has not been justified and rolls back the operations to their original state, but the data processed during speculative execution sits in the cache and microarchitecture buffers and is available for extraction using various residual data determination methods through third-party channels.
Gadget Scan Tools based on patterns previously available for the Spectr vulnerabilitye showed a very high rate of false positives, while many real gadgets were lost (experiments showed that 99% of the gadgets detected by such tools could not be used for attacks, and 33% of the working ones were not observed devices capable of leading to an attack).
Introducing Kasper, a transient (or speculative) execution device scanner. It uses corruption analysis policies to model an attacker capable of exploiting arbitrary software/hardware vulnerabilities in a transient path.
About Casper
To improve quality of the identification of problematic devices, Kasper models the vulnerabilities that an attacker can use at each step of Spectre-class attacks: problems are modeled to allow data control (for example, substitution of attacker data into microarchitectural structures to influence subsequent speculative execution) using LVI-class attacks , gain access to sensitive information (for example, when the buffer is out of bounds or memory is used after it has been freed), and leak sensitive information (for example, by parsing the state of the processor cache or using the MDS method ).
Model an attacker capable of controlling data (eg, via memory massage or LVI value injection), accessing secrets (eg, via out-of-bounds access or use after free ) and leak these secrets (eg, through cache-based, MDS-based, or port contention-based covert channels).
When performing the test, kernel contacts runtime libraries by Kasper and verify that they work at the LLVM level. During verification, speculative code execution is emulated by the checkpoint restore mechanism, which specifically executes an incorrectly predicted fork of code, after which it returns to its original state before the fork began.
Kasper also tries to model various software and hardware vulnerabilities, analyzes the influence of architectural and microarchitectural effects and performs fuzzing tests of possible attacker actions. For the analysis of the execution flows, the DataFlowSanitizer port for the Linux kernel is used, and for the fuzzing tests, a modified version of the syzkaller package.
As a result, Kasper discovered 1.379 previously unknown devices in the heavily hardened Linux kernel. We confirmed our findings by demonstrating an end-to-end proof-of-concept exploit for one of the devices found.
While scanning the Linux kernel with Kasper, 1379 previously unknown devices were identified, which could lead to data leakage during speculative execution of instructions.
It is noted that perhaps only some of them can present real problems, but to show that there is a real danger, and not just a theoretical one, a working prototype of an exploit was developed for one of the problematic code snippets, which led to a leak of kernel memory information.
Finally if you are interested in knowing more about it about Kasper, you should know that the source code It is distributed under the Apache 2.0 license.
Source: https://www.vusec.net