Hello, On Mon, Jan 23, 2012 at 09:06:38PM +0200, Török Edwin wrote: > PIE refers to -fPIE from GCC of course.
First, let me thank you for your report, Edwin. > Using that flag doesn't completely prevent the > exploit though. How unfortunate, > Here is a good summary and discussions: > https://lwn.net/Articles/476684/ > > > References I could find indicate an issue in > > the Linux kernel handling of /proc/<pid>/mem Well, in vanilla grsec you'll not even see /proc/<pid> of the process which is running as different user (euid). This made it inconvenient for me to use Debian standard pon/poff scripts and I hacked my own grsec to allow seeing /proc/<pid> for the processes that run with ruid == my-uid too (so I'd be vulnerable if my kernel was 2.6.39 AFAIU). > Apparently packages should adopt hardening flags > for wheezy: > http://wiki.debian.org/Hardening#State_of_implementation Well, what I see is someome (Linus?) did a major fuckup in Linux kernel 2.6.39 enabling the exploit in the first place. Then the said fuckup was discovered, but all went silent until a guy posts working exploit code on the Internet. Now, _we_ are requiered to compile with -fPIE to make exploiting harder (presumably). But then I see this post from the person I trust more than Linus or Cox taken together: Posted Jan 23, 2012 15:49 UTC (Mon) by PaXTeam (subscriber, #24616) [Link] > Posted Jan 23, 2012 15:10 UTC (Mon) by corbet > (editor, #1) [Link] > > As it happens, Fedora's su is dynamically > > linked, so it's probably not vulnerable to > > this particular exploit anyway (though the > > kernel vulnerability remains and may be > > exploitable via some other path). > > the exploit can take the target address as > argument, it's a trivial one-liner to brute > force it... and the other one: Posted Jan 23, 2012 17:20 UTC (Mon) by PaXTeam (subscriber, #24616) [Link] > 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). So do as you see fit, it's Debian after all. Debian can force all its maintainers to comply and build everything with -fPIE as it pleases. IMO this will prevent script kiddies only, and only until nextgen mempodipper appears. Then we have pwned CAs and alike. -- With best regards, xrgtn -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
