[Pkg-shadow-devel] Bug#657010: Bug#657010: [login] 'su' should be PIE
xrgtn at yandex.ru
Tue Jan 24 07:54:57 UTC 2012
On Mon, Jan 23, 2012 at 09:06:38PM +0200, Török
> 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.
> Here is a good summary and discussions:
> > 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
> Apparently packages should adopt hardening flags
> for wheezy:
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
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
> 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
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,
More information about the Pkg-shadow-devel