C++ Memory Corruption - part 1

  Dr Silvio Cesare @silviocesare Summary C++ is a popular systems programming language. As such, it is desirable to develop exploitation primitives for this language since many exploitation targets will be written in C++. This blog posts looks at 2 C++ specific exploitation techniques when STL objects are subject to memory corruption. In particular, we will examine vector iterators and smart pointers in Linux on Ubuntu 20.04. Introduction Generic or abstract data types are implemented in C++ using a library known as STL or the standard template library. Typical STL containers include abstract data types such as linked lists, vectors, arrays, associative maps, sets, and hash tables. As part of STL, iterator classes exist to navigate through their appropriate data structure. Different types of iterators exist for particular STL objects. For example, a singly linked list implemented as the STL forward_list, only allows iteration in a single direction. Thus a forward iterator is mor

Double Frees in Chrome's Partition Alloc - part 2

Dr Silvio Cesare @silviocesare Summary PartitionAlloc is the hardened heap allocator used in Google's Chrome web browser. It is susceptible to a number of attacks. This blog post describes the second attack in a series of posts. I will talk about double frees and how to make an allocation request return an arbitrary pointer. This can be used with application-logic to develop an arbitrary write primitive. Introduction In heap allocators, freelists maintain a group of free memory chunks that are available to be recycled by an allocation request. Freelist poisoning corrupts this list and injects a "fake chunk" pointer. A later allocation will return this fake chunk pointer. So it is possible to make an allocation request return an arbitrary pointer. A double free often creates a cycle in the freelist. When a chunk is returned by an allocation request, the chunk still remains in the freelist. Thus, if an attacker writes to that chunk, it is use-after-free

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 . A subsequent patch was written by Kees Cook in https://git.

Bypassing Pointer Guard in Linux's glibc

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 . The mitigation provides a set of macros that mangle and demangle pointers. The API to use

Breaking Secure Checksums in the Scudo Allocator

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

InfoSect Coronavirus (COVID-19) Announcement

InfoSect prides itself in providing high-quality, in person training with low student numbers per class and specialised instruction from our trainers. However, with the current Coronavirus pandemic sweeping the world, we understand this is not feasible for the near to medium term. During this time InfoSect is planning to run live, interactive training courses. What does this mean for students? Students will be provided a link the day before training starts to log into a virtual classroom. The virtual classroom will include a live stream of Silvio teaching the course. Students will be able to ask questions and engage live with Silvio during the course. Lab guides will be provided in soft copy instead of hard copy. Hands-on labs will be facilitated remotely, with the same hands-on, interactive challenges. InfoSect swag will be posted following the course. Requirements to attend: A place to study. An Internet connection. A laptop with a browser and capable of SSH. A m