Date:	Tue, 23 Dec 2014 00:23:47 +0100
From:	Hector Marco Gisbert <hecmargi@....es>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Ingo Molnar <mingo@...hat.com>,
	Anton Blanchard <anton@...ba.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>,
	David Daney <ddaney.cavm@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arun Chandran <achandran@...sta.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Ismael Ripoll <iripoll@...ca.upv.es>,
	Christian Borntraeger <borntraeger@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Hanno Böck <hanno@...eck.de>,
	Will Deacon <will.deacon@....com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Kees Cook <keescook@...omium.org>,
	Reno Robert <renorobert@...il.com>
Subject: Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib
 attack

> Before I even *consider* the code, I want to know two things:
  >
  > 1. Is there actually a problem in the first place?  The vdso
  > randomization in all released kernels is blatantly buggy, but it's
  > fixed in -tip, so it should be fixed by the time that 3.19-rc2 comes
  > out, and the fix is marked for -stable.  Can you try a fixed kernel:
  >
  >
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=x86/urgent&id=fbe1bf140671619508dfa575d74a185ae53c5dbb


Well if it is already fixed, then great!.

But since the vdso is something like a library (cause it contains code,
and no data), it shall be handled as a library and so it shall be
located jointly with the other libraries rather than close to the stack.
Later I'll talk about randomizing libraries among them.

I think that the core idea of the current ASLR implementation is that
all the areas that share similar content (libraries, stack, heap,
application) shall be placed together. Following more or less the MILS
division. This way, a memory leak of an address of the stack is not very
useful for building a ROP on the libraries.

Another issue is the page table locality. The implementation tries to
allocate the vdso "close" to the stack so that is fits into the PMD of
the stack (and so, use less pages for the pagetables). Well, placing the
vdso in the mmap area would solve the problem at once.

Unfortunately, with your path the VDSO entropy has 18 entropy bits. But
this is not true. The real entropy is masked with the entropy of the
stack. In other words, if an attacker guesses where the stack is placed
they have to do negligible work to guess where the VDSO is located.
Note that, a memory leak from a data area (which is of little help to
the attacker) can be used to locate the VDSO (which is of great interest
because it is executable and contains nice stuff).

Using my solution, the VDSO will have the same 28 bits of randomness
than the libraries (but all will be together).

After after 10000 executions I have found 76 repeated addresses (still
low entropy, but much better than before). But with my patch, there was
no repetition (much better entropy).


  > 2. I'm not sure your patch helpes.  The currently exciting articles on
  > ASLR weaknesses seem to focus on two narrow issues:
  >
  > a. With PIE executables, the offset from the executable to the
  > libraries is constant.  This is unfortunate when your threat model
  > allows you to learn the executable base address and all your gadgets
  > are in shared libraries.

Regardes the offset2lib... The core idea is that we shall consider the
application code and libraries as two slightly different things (or two
different security regions). Since applications are in general more
prone to have bugs than libraries, it seems that this is the way to do
it from the security point of view.  Obviously, stack and libraries are
clearly apart (you can even assign different access permissions).
Application code and libraries are not that different, but it would be
better of they are not together.... and sincerely, I think that the cost
of allocate them apart is so small that it worth the code.

If the extra cost of (One or two pages) per process required to place
the application code to another area is too high, then may be it can be
implemented as another level of ASLR randomize_va_space=3 (if any).


  > b. The VDSO base address is pathetically low on min entropy.  This
  > will be dramatically improved shortly.
  >
  > The pax tests seem to completely ignore the joint distribution of the
  > relevant addresses.  My crystal ball predicts that, if I apply your
  > patch, someone will write an article observing that the libc-to-vdso
  > offset is constant or, OMG!, the PIE-executable-to-vdso offset is
  > constant.
  >
  > So... is there a problem in the first place, and is the situation
  > really improved with your patch?
  >
  > --Andy

Absolutely agree.

The offset2x shall be considered now. And rather than moving objects
like the vdso, vvar stack, heap... etc.. etc.. we shall consider
seriously the cost of a full (all maps) to be real random. That is
inter-mmap ASLR.

Current implementation is not that bad, except that the application was
considered in the same "category" than libraries. But I guess that it
deserves a region for its own. Also, I think that executable code shall
be apart from data.. which supports the idea of inter-mmap randomization.

Sorry if I'm mixing VDSO, and offset2lib issues, but they share a
similar core problem.


--Hector Marco.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists