Sanity check the forward and backward chunk pointers in the unlink() macro used by Doug Lea's implementation of malloc(3). If the pointers are determined to have been overwritten, the process will be forced to terminate thereby reducing the impact of a common class of attacks on memory overwrite vulnerabilities present in various applications. Credit for the idea for this countermeasure is due to Stefan Esser. 2003/11/29 kernel SECURITY FIX Severity: high, local, active --------------------------------------------------------------------------------- A patch was recommended to me a while back for glibc which adds sanity checks for forward/reverse pointers for the unlink() macro of glibc. However I was hesitant about suggesting it be use within our distro without a quite a bit of testing. Well I've been testing it for quite a while now and I'm now going to suggest that it be reviewed by our base-system, gcc-porting teams for inclusion. First it's important that you/we understand the problem. http://www.phrack.org/phrack/61/p61-0x06_Advanced_malloc_exploits.txt After reading that. Please review the proposed patches which I've fwd ported from the openwall version. I've inquired why this patch is not in the upstream glibc and the answer I've gotten is simply 'cos no one thought of it beyond Stefan Esser who published it finally. And the simple things tend to be the least obvious sometimes.
Created attachment 24033 [details, diff] glibc-2.3.3_pre20031222.ebuild.diff
Created attachment 24034 [details, diff] glibc-2.3.3-owl-malloc-unlink-sanity-check.diff
You did see the note in the conclusion about glibc-2.3* ?
The Note by the editors? ------------------------------------------------- [ Note by editors: It came to our attention that the described technique might not work for the glibc 2.3 serie. ] ------------------------------------------------- If so I saw it but I've seen no changes in the unlink() macro itself in glibc itself so I assume the editors note is incorrect. My heap is not executable in the first place so I have no easy way to verify if this holds true or not.
If you can mail me an exploit to check it, I can verify ...
In the end I would end up mailing you link back to http://www.phrack.org/phrack/61/p61-0x06_Advanced_malloc_exploits.txt so I don't think I will provide exploit code or would hopefully need to seeing as this is just a basic sanity check for when glibc free's memory internally. If need be we could email Stefan Esser and ask him for his input on this bug.
*** Bug 37763 has been marked as a duplicate of this bug. ***
merged in ~arch
