[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 08 Dec 2014 08:24:32 +0100
From: Lionel Debroux <lionel_debroux@...oo.fr>
To: oss-security@...ts.openwall.com
Subject: Re: How GNU/Linux distros deal with offset2lib attack?
On 07/12/2014 20:44, Greg KH wrote:
> On Sun, Dec 07, 2014 at 10:43:17PM +0800, Shawn wrote:
> > Hi Lionel,
> >
> > Thanks for your extraordinary explanation about Grsec/PaX. I'm a
> > big fan of Grsec/PaX. But I think compare the ASLR implementation
> > of vallina kernel with Grsecurity/PaX is not fair. Linux upstream
> > doesn't hold the security-oriented philosophy, while
> > Grsecurity/PaX community are expertise of system-lvl security.
> Ok, do you seriously think this? If so, please provide details as
> to why you feel this way. The Linux kernel developers take security
> very seriously, otherwise no one would be using Linux for "secure"
> systems, right?
While Linux is clearly rather secure in _relative_ terms (far more
secure than classic Windows, etc.), showing that mainline pays some
amount of attention to security, people who really want a more secure
Linux in _absolute_ terms don't use mainline Linux, because they know
that PaX/grsec provide _much_ more attention to security ;)
Elevator pitch:
* PaX/grsecurity contains various generic protections which don't exist
on mainline against exploit techniques / exploit helpers (e.g.
infoleaks) which have been known for sometimes over a decade;
* PaX/grsecurity has stronger mitigations than mainline for some
mitigations that mainline also implements - e.g. for ASLR, the trigger
for this discussion;
* backports for security fixes are usually performed more quickly in
PaX/grsec than in mainline, stable kernels.
It's common for PoC not to work on PaX/grsec kernels (spender usually
twits or posts on LWN); making exploits work there would require (much)
more effort. Running an outdated PaX/grsec kernel is safer than running
a HEAD mainline kernel.
Now for some specific examples:
1) an example representative of the above is
https://lwn.net/Articles/598372/ from May. Look at the first 4 posts if
you don't have time; however, other, later posts are also interesting,
e.g. spender showing how easily mainline KASLR can be defeated, even
from within a seccomp sandbox, which is largely why he and PaXTeam never
bothered.
* the security backport (for one of the most dangerous holes in the
Linux kernel) was pushed to grsec 3.2 and 3.14 over a week before it was
pushed to mainline 3.2 and 3.14 (second post, by myself);
* two generic PaX/grsec defeats kill the published exploit for sure, one
probabilistically kills it (different struct layout - of course, that
only really helps if the attacker isn't able to download your kernel),
and a fourth generic protection, stronger than mainline's, makes it
harder to get information about addresses.
2) likewise, Luto's PoC for CVE-2014-5207 (
http://seclists.org/fulldisclosure/2014/Oct/33 ) uses an operations
structure in userspace, so MEMORY_UDEREF and KERNEXEC kill the exploit.
Kernels with MEMORY_UDEREF and KERNEXEC enabled do not blissfully
dereference operations struct in userspace and do not blissfully execute
arbitrary user-provided userspace code, which is, uh, not so secure, right ?
Before someone makes the usual blunder of pointing out SMAP as an
equivalent to MEMORY_UDEREF: PaXTeam reminded, in the
https://lwn.net/Articles/617895/ thread, that PaX's MEMORY_UDEREF is a
strict superset of Broadwell's SMAP, and that SMAP could be made more
useful (but I don't know how).
What's more, MEMORY_UDEREF, unlike Broadwell's SMAP, which requires
special hardware support, has worked for years on thousands of computers
across multiple architectures...
That thread also points out that PaX leverages the PCID capability of
modern x86_64 processors; mainline has no support for it.
PaX/grsecurity can be used alongside existing LSMs, since it modifies
the kernel at the appropriate, lower level. PaX focuses on preventing
exploitation, rather than on enforcing policy.
Lionel.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
