Posts

Showing posts from April, 2020

Bit Flipping Attacks Against Free List Pointer Obfuscation

Dr Silvio Cesare @silviocesare Summary  In this blog post, I look at attacks to make an obfuscated free list pointer, such as that used in the Linux kernel, demangle or descramble to an arbitrary address. The way I do this, is to substitute the stored and obfuscated pointer with a pointer of my choosing and then take note of errors reported by the resulting invalid pointer once it has been demangled. Using bitwise arithmetic, I am able to take these invalid pointers and construct a new substitute pointer such that demangling returns to me a near arbitrary pointer. Introduction Free list pointers are used in the default Linux kernel heap allocator, SLUB. A free list pointer holds the address of the next available chunk of memory. If an attacker is able to corrupt or poison this pointer, they might make a heap allocation return a somewhat arbitrary pointer. In the Linux kernel, this pointer is not entirely arbitrary because the pointer is validated to belong to the appropriate

An Analysis of Linux Kernel Heap Hardening

Dr Silvio Cesare @silviocesare Summary  I wrote a blog post some months ago on weaknesses in the Linux kernel heap free list pointer hardening implementation. In response to that weakness, Kees Cook wrote an improved kernel patch, which I reviewed. This blog post is an analysis of that patch. I try to break it using an SMT solver and fail. Introduction In the original kernel slab free list hardening patch, the free list pointer was scrambled to prevent naive free list pointer corruption and poisoning. The scrambling consisted of: obfuscated_ptr = ptr ^ ptr_addr ^ secret The weakness in this approach was because ptr and ptr_addr were part of the same slab, they were highly similar. In fact, only the low bits were different. As such, the obfuscated_ptr revealed almost the entire secret. The blog post where I talk about this is here https://blog.infosectcbr.com.au/2020/03/weaknesses-in-linux-kernel-heap.html . A subsequent patch was written by Kees Cook in https://git.

Bypassing Pointer Guard in Linux's glibc

Image
Dr Silvio Cesare @silviocesare Summary  Pointer guard is an exploit mitigation in glibc that applies to stored pointers and especially stored function pointers. A number of library calls can register function pointers that get executed later on. An example of this is registering an exit handler with atexit(). Stored function pointers are scrambled or mangled by XORing them with a secret in the thread data (fs:0x30) and applying a bitwise rotation. This mitigates control-flow hijacking by an attacker who would otherwise be able to overwrite the stored function pointer with a location of their choosing. In this blog post, I'll present a bypass for pointer guard in multithreaded applications where an attacker knows the libc base address and has an arbitrary read. Introduction Pointer guard is documented in glibc reference materials https://sourceware.org/glibc/wiki/PointerEncryption . The mitigation provides a set of macros that mangle and demangle pointers. The API to use

Breaking Secure Checksums in the Scudo Allocator

Image
Dr Silvio Cesare @silviocesare Summary  Scudo is a hardened heap allocator used in Android. Scudo has a security mechanism where malloc chunk headers include a CRC32 checksum that incorporate the malloc chunk pointer and an out of band secret 32-bit cookie. In this blog post, I assume I am able to leak a malloc chunk header and the pointer to it. From that, I infer the secret cookie by solving a set of equations that model the checksum algorithm using the z3 and STP SMT solvers, such that I can create my own checksums for fake chunk headers. Introduction Scudo is a hardened allocator as used in Android. To use scudo is quite simple with the clang compiler and a compiler option. $ clang -fsanitize=scudo test.c -o test A malloc chunk has an 8-byte header. This header is defined as: The 16-bit checksum uses the CRC32 algorithm and incorporates the pointer to the malloc payload and a secret 32-bit cookie that is not stored in the header. The CR