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 debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
