Date: Sun, 07 Dec 2014 13:08:00 +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 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.
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.