3 ms·

So WinAFL is a C/C++ program? So they debugged a Rust OOB access bug in the Windows Kernel with a C/C++ program? A bug in Rust component that could have led to

• aw1621107 11mo ago
  > A bug in Rust component that could have led to Windows kernel compromise I don't think this bug could have led to a kernel compromise unless you count a DoS as a kernel compromise, which I'm a bit skeptical of. From the article: > Notably, the system crash was triggered by this new kernel component designed to improve security, as suggested by the name of the panic_bounds_check() function referenced in the stack trace shown in Figure 2. Later: > When the region_from_path_mut() function converts a path into a region it represents the outline as a singly linked list of edge blocks. The program detects the out-of-bounds memory access via core::panicking::panic_bounds_check() and triggers a SYSTEM_SERVICE_EXCEPTION. And from Microsoft's assessment of the bug: > “the Rust code correctly catches an out-of-bounds array access and triggers a panic, resulting in a Blue Screen of Death (BSOD), as expected” Furthermore, from the implementation of core::panicking::panic_bounds_check() [0]: #[lang = "panic_bounds_check"] // needed by codegen for panic on OOB array/slice access fn panic_bounds_check(index: usize, len: usize) -> ! { ... } So you have an attempted OOB access, but since (safe) Rust guarantees OOB accesses will panic I don't think there's a path to escalate the DoS to a full kernel compromise short of an optimizer bug and/or the use of unsafe, for which there doesn't appear to be evidence for either. [0]: https://doc.rust-lang.org/stable/src/core/panicking.rs.html https://doc.rust-lang.org/stable/src/core/panicking.rs.html