CODEWITHSUNDEEP
csecurityheap-memoryglibcexploit
James Preston
James Preston

Reputation: 91

Information on glibc heap protection mechanisms?

Is there any information on what measures glibc takes to make heap-based exploits more difficult? I've heard of a few things like PTR_MANGLE and some nebulous "heap consistency checking" on the security feature list pages of several Linux distributions, but I've not been able to find detailed information on how these mechanisms are actually implemented, if they are effective, and what vulnerability classes they encompass. Even when searching for the mentioned features by name I wasn't able to find any glibc documentation on them.

So what features are implemented, and how well do they work? Does glibc have any kind of heap consistency checking mechanism that is similar to the stack smashing protector on the stack? Does PTR_MANGLE "encrypt" all pointers, or just a subset of them? And most importantly, can these features be switched on by the end user, or do they depend on some specific API being used so that I have to hope that whoever wrote the programs I use actually enabled the protection mechanisms?

Upvotes: 1

Views: 690

Answers (1)

Mike Frysinger
Mike Frysinger

Reputation: 3072

PTR_MANGLE is an internal implementation of glibc itself and has no effect on pointers used by programs. it is also not something that can be turned on/off on the fly or for specific programs. it only protects internal glibc data structures that are opaque to programs, and even then, it only focuses on ones that can be used to hijack code flow directly (i.e. vtables/function pointers). it isn't used for general data (e.g. counters).

currently i don't believe glibc is using guard pages for the heap, but people are working on it. you can try searching the upstream mailing list for recent posts on the topic. it has long used guard pages for the stack, but those are more for blowing the stack rather than stack canaries (ssp).

Upvotes: 1

Related Questions