| |||||||||||||
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)Posted Jan 24, 2012 4:24 UTC (Tue) by eteo (guest, #36711)In reply to: Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) by PaXTeam Parent article: Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4)
Obviously this is work-in-progress. Don't expect that I know everything. If you have something to contribute, do so. Thanks.
(Log in to post comments)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 12:59 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
a few things come to mind:
1. as i mentioned it here already, why do the mem_* accessors use force=true when accessing the address space? was that a design decision?
2. why's mem_read not mentioned at all? it has the same buggy logic, it's just waiting for a suitable suid to disclose sensitive information...
3. Linus' fix turned this bug into a kind of local DoS (default ulimits on most systems allow one to eat up memory) where the culprit cannot be easily identified (since the zombie mm's memory consumption is not accounted to the process holding the refcount/fd). is a new CVE in order? ;)
Linux Local Privilege Escalation via SUID /proc/pid/mem Write (zx2c4) Posted Jan 24, 2012 13:31 UTC (Tue) by PaXTeam (subscriber, #24616) [Link]
one more thing:
4. i don't know if gdb and similar use /proc/pid/mem but if they do, they'll be broken when they want to trace across an execve without reopening /proc/pid/mem as it is required now. but since Linus has yet to revert/properly fix the heap-stack gap commit as well, i think this one's going to stay too.
|
|||||||||||||