[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 7 Dec 2014 22:43:17 +0800
From: Shawn <citypw@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: How GNU/Linux distros deal with offset2lib attack?
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. Developer/users could take bear
of 5%-10% performance penalty caused by new features, but I don't
think most developers/users would accept even 1% performance penalty
caused by security defensive mitigation. Personally, I hope we could
see Grsecurity/PaX being part of mainline linux kernel in the future.
IMOHO, offset2lib is a very critical impact to the GNU/Linux
mitigation. What if the bad buys already have some 0day vulns? This
will make their work so much easier to write massive exploit. Hope
upstream could patch this issue as quickly as possible. Plz don't let
this work to the burden of GNU/Linux distro community.
On Sun, Dec 7, 2014 at 8:08 PM, Lionel Debroux <lionel_debroux@...oo.fr> wrote:
>> On Sat, Dec 6, 2014 at 7:35 PM, Greg KH <greg@...ah.com> wrote:
>> > On Sat, Dec 06, 2014 at 03:22:58PM +0800, Shawn wrote:
>> > >
>> > > 2, ASLRv3? Hector Marco( the dude who disclosured offset2lib
>> > > attack) sent a patch to the upstream:
>> > > https://lkml.org/lkml/2014/12/4/839
>> > >
>> > > Even the upstream don't accept the patch, is this possible to
>> > > backport it & maintain it for distro community?
>> >
>> > Upstream asked for some basic fixes to the patch (i.e. it wasn't
>> > submitted in the needed format) before it could accept it, so I
>> > doubt it's rejected yet.
>> >
>> > And of course a distro could backport and maintain it, it's a very
>> > tiny patch, much smaller than what they normall backport. Take it
>> > up with the distros if you want this.
> Tiny indeed. I'm surprised how few hunks it contains, given that
> PAX_ASLR involves
> $ grep CONFIG_PAX_ASLR pax-linux-3.17.4-test7.patch | wc -l
> 25
> hunks.
>
> Is Hector Marco's ASLRv3 submission a much simpler reinvention of PaX's
> ASLR wheel, or is it rather a smaller wheel which does less than PaX's
> improved, field-tested ASLR does ?
> If the latter, I think it wouldn't be good to see another half-measure
> integrated to mainline, until the next mainline ASLR defeat against
> which PaX has protected for over a decade. Just my 2 cents.
>
>
> On 06/12/2014 17:48, Loganaden Velvindron wrote:
>> Going through the LKML mailing discussion, it seems that there's
>> interest in improving the diff according to the comment by Andy.
> Andy suggests "randomly-sized guard regions between all libraries".
> Is it already a side effect of PAX_RANDMMAP ?
>
> config PAX_RANDMMAP
> bool "Randomize user stack and mmap() bases"
> depends on PAX_ASLR
> select PAX_RANDUSTACK
> help
> By saying Y here the kernel will randomize every task's userland
> stack and use a randomized base address for mmap() requests that
> do not specify one themselves.
>
> The stack randomization is done in two steps where the second
> one may apply a big amount of shift to the top of the stack and
> cause problems for programs that want to use lots of memory (more
> than 2.5 GB if SEGMEXEC is not active, or 1.25 GB when it is).
>
> As a result of mmap randomization all dynamically loaded libraries
> will appear at random addresses and therefore be harder to exploit
> by a technique where an attacker attempts to execute library code
> for his purposes (e.g. spawn a shell from an exploited program that
> is running at an elevated privilege level).
>
> Furthermore, if a program is relinked as a dynamic ELF file, its
> base address will be randomized as well, completing the full
> randomization of the address space layout. Attacking such programs
> becomes a guess game. You can find an example of doing this at
> http://pax.grsecurity.net/et_dyn.tar.gz and practical samples at
> http://www.grsecurity.net/grsec-gcc-specs.tar.gz .
>
> NOTE: you can use the 'chpax' or 'paxctl' utilities to control this
> feature on a per file basis.
>
> There's a use case for turning this feature off; perhaps relevant to
> some users on some 32-bit platforms, but probably not on 64-bit platforms.
>
> FWIW:
> $ grep CONFIG_PAX_RANDMMAP pax-linux-3.17.4-test7.patch | wc -l
> 62
> $ grep CONFIG_PAX_RANDUSTACK pax-linux-3.17.4-test7.patch | wc -l
> 6
> (4 of which are on the same lines as CONFIG_PAX_RANDMMAP)
>
>
> Bye,
> Lionel.
--
GNU powered it...
GPL protect it...
God blessing it...
regards
Shawn
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.
