[Pkg-shadow-devel] Bug#657010: Bug#657010: [login] 'su' should be PIE

[Alexander Gattin]

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