LWN.net Logo

Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)

Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)

Posted Jan 23, 2012 17:20 UTC (Mon) by PaXTeam (subscriber, #24616)
In reply to: Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) by cesarb
Parent article: Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)

i understand you're excited but please stick to the facts... ASLR won't make exploitation 'much harder' given the few bits one has to brutefoce, call it a blink of an eye. if you have something like grsecurity's brute force detection and prevention feature then you can at least bound the probability of success (but still not make it 0, and also let's not forget about potential memory leaks one could make use of to avoid brute forcing in the first place although for this particular vulnerability it's very hard to imagine a situation where such leaks could be used by the exploit given how the lseek has to happen before the suid address space even exists).

second, mem_write makes use of the same accessor underneath as ptrace and can therefore write to memory mapped as read-only (whether that capability was intended or not is another question and perhaps a bug itself yet to be fixed). so RELRO/etc won't do anything to prevent this vulnerability from getting exploited. case in point, this exploit modifies the .plt section itself that is mapped as read-only already. i will note again that under grsecurity the technique used in this exploit won't work because PaX prevents said accessor from modifying executable (and hence read-only) mappings, one would need a ret2libc style exploit and most likely brute force (which is then limited by the previously mentioned feature).


(Log in to post comments)

Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)

Posted Jan 24, 2012 10:12 UTC (Tue) by atomik (subscriber, #69705) [Link]

So what about some features of pax/grsecurity in the mainline kernel if it can prevent some security issue ?

The same story as with Android

Posted Jan 24, 2012 10:38 UTC (Tue) by khim (guest, #9252) [Link]

Security people hit the same wall Android developers did: tradeoffs "obvious" to them are not all that obvious to mainline kernel developers. Since absolute security is impossible and we already have one kernel 100% focused to security (OpenBSD) it means mainline kernel developers should be convinced in merits of each and every change separately. But this will improve security by itself is not enough if it'll complicate other things, affect speed or reliability, etc.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds