Freelist Heap Exploitation on Docker Alpine Linux Images

Introduction

In this blog post, I'll look at 2 attacks on Alpine Linux distributions, which is common with Docker images. Both attacks will use freelist poisoning against the heap allocator. The difference is that the first attack will look at uClibc's heap allocator which is present in earlier releases of Alpine, and the second attack will look at the current version of Alpine, which uses musl libc.

I have written at great length about freelist poisoning, as seen in:

https://blog.infosectcbr.com.au/2019/07/linux-heap-tcache-poisoning.html
https://blog.infosectcbr.com.au/2019/09/linux-heap-fast-bin-poisoning-part-1.html
https://blog.infosectcbr.com.au/2019/09/linux-heap-fast-bin-poisoning-part-2.html
https://blog.infosectcbr.com.au/2019/11/avr-libc-freelist-poisoning.html
https://blog.infosectcbr.com.au/2019/12/attacks-on-tcmalloc-heap-allocator.html

The main feature of freelist poisoning is that an attacker is able to make malloc return an arbitrary pointer. Combine with appropriate application logic, this can enable an arbitrary write to memory.

uClibc Freelist Poisoning

Here is freelist poisoning on uClibc.

Musl Freelist Poisoning

Here is freelist poisoning on the latest Alpine distribution, which uses musl libc. It is almost identical to the earlier freelist poisoning, with minor variations.

Conclusion

In this blog post I demonstrated 2 attacks on the heap allocators used in the Alpine Linux distribution. Other attacks are possible and will be examined in future posts.

If you are interested in exploitation, consider InfoSect's 2, 3, and 5-day training on Heap Exploitation https://www.eventbrite.com.au/e/linux-heap-exploitation-tickets-48997946176

Attacks on the TCMalloc Heap Allocator

Introduction

TCMalloc is a well known heap allocator. It is written by Google. A number of attacks against tcmalloc are possible. A good presentation on tcmalloc was given in 2011, https://downloads.immunityinc.com/infiltrate-archives/webkit_heap.pdf

In this blog post, I'll give examples of 3 attacks, some of which are not well known.

Freelist Poisoning

In the following code, we make tc_malloc return an arbitrary pointer. This is another variant of freelist poisoning, which I have talked about at great length. For freelist poisoning details on other allocators, see:

https://blog.infosectcbr.com.au/2019/07/linux-heap-tcache-poisoning.html
https://blog.infosectcbr.com.au/2019/09/linux-heap-fast-bin-poisoning-part-1.html
https://blog.infosectcbr.com.au/2019/09/linux-heap-fast-bin-poisoning-part-2.html
https://blog.infosectcbr.com.au/2019/11/avr-libc-freelist-poisoning.html 

Double Free

In the following attack that exploits a double free in tcmalloc, we convert the double free into freelist poisoning and thus are able to obtain an arbitrary write primitive. I've talked about this attack before on other allocators. For example:

https://blog.infosectcbr.com.au/2019/07/linux-heap-glibc-227-double-free.html 
https://blog.infosectcbr.com.au/2019/08/linux-heap-fast-bin-double-free.html 
https://blog.infosectcbr.com.au/2019/09/linux-heap-glibc-tcache-double-free.html 

The code above takes advantage that a cycle has formed in the freelist. Thus, a malloc returns a buffer, but that buffer is start of the freelist. Thus, freelist poisoning can happen on the allocated buffer.

Overlapping Chunks

The final attack we'll look at in tcmalloc is creating overlapping chunks via a free of an arbitrary pointer. This attack is different to the house of spirit. Since tcmalloc is a bucket-style allocator, when a pointer is freed, it has to belong to a bucket. TCMalloc doesn't check for pointer alignment to that bucket's object before putting the pointer on the freelist. Thus, a non-aligned object pointer is in the freelist and is returned for that bucket of the appropriate object size. The pointer is unaligned but still services the object size, and thus overlaps the adjacent chunk.

Conclusion

In this blog post, I gave examples of 3 attacks against tcmalloc. These attacks can lead to a variety of exploitation primitives such as arbitrary writes to memory and overlapping chunks. They serve as useful tools in the exploit developers toolkit.

If you are interested in exploitation, consider InfoSect's 2, 3, and 5-day training on Heap Exploitation https://www.eventbrite.com.au/e/linux-heap-exploitation-tickets-48997946176

 

 

Newlib Unlink Heap Exploitation

In this paper, I introduce the reader to a heap metadata corruption against the latest version of newlib. This allocator is used in embedded systems. The unlink attack on heaps was first introduced by Solar Designer in the year 2000 and was the first generic heap exploitation technique made public. The same attack is possible in modern day uClibc and the attack in newlib is almost identical. In the unlink technique, an attacker corrupts the bk and fd pointers of a free chunk. In a subsequent malloc that recycles this chunk, the chunk is unlinked from its freelist via pointer manipulations. This inadvertently allows an attacker to craft a write-what-where primitive and write what they want where they want in memory. The unlink attack name stemmed from the fact that the unlink macro is the code that performs the pointer manipulation to unlink the free chunk. This macro is unchanged in newlib and is also called unlink.

 Newlib Unlink Heap Exploitation.PDF