Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 07 Dec 2014 13:08:00 +0100
From: Lionel Debroux <>
Subject: Re: How GNU/Linux distros deal with offset2lib attack?

> On Sat, Dec 6, 2014 at 7:35 PM, Greg KH <> 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:
> > >
> > >
> > > 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

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 ?

bool "Randomize user stack and mmap() bases"
depends on PAX_ASLR
  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 and practical samples at .

  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.

$ grep CONFIG_PAX_RANDMMAP pax-linux-3.17.4-test7.patch | wc -l
$ grep CONFIG_PAX_RANDUSTACK pax-linux-3.17.4-test7.patch | wc -l
(4 of which are on the same lines as CONFIG_PAX_RANDMMAP)


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.