Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

[Andy Lutomirski]

On Tue, Dec 23, 2014 at 12:07 AM, Reno Robert <renorobert@xxxxxxxxx> wrote:
> Hi Andy,
>
> I would like to mention couple of things
>
> 1. With reference to details mentioned in vdso patch, there are ~76 repeated
> address in 10000 runs. This may not be good enough. Consider the case of
> local exploitation, one can still easily bruteforce the address and use
> gadgets in vdso without any information leak. Even in network daemon, if it
> restarts, bruteforce is still feasible. vdso has enough good code to chain a
> proper exploit, so its randomization should be considered serious.
>
> Also i'm not sure if there could be any modulo bias in the new patch with
> respect to offset computation.

There is a bias: the vdso end address is most likely to be at the end
of a PMD.  That bias is much, much smaller than before, though.

Keep in mind, though, that 76 repeated addresses in 10k runs isn't so
terrible, as an attacker won't know *which* 76 addresses will repeat.
But yes, this won't prevent an exploit by an attacker who can try many
thousands of times.

>
> 2. As Hector already mentioned, if someone could figure out the address of
> an executable segment(vdso in this case) by knowing an address of data area
> (stack), this may not be desirable. I agree that some information leak is
> needed here.

There are two reasons I don't want to just treat the vdso like every other dso:

1. Compatibility.  Changing that would not be okay for stable kernels,
whereas my patch doesn't change the allowed range.

2. I'd like to make sure it's not worse for some reason.  The vdso has
very well known contents, and if you can somehow jump somewhere
relative to another dso's code or data, then it could be used for an
exploit.  I don't know how realistic that is.

--Andy

>
>
> On Tue, Dec 23, 2014 at 5:08 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx>
> wrote:
>>
>> On Mon, Dec 22, 2014 at 3:23 PM, Hector Marco Gisbert <hecmargi@xxxxxx>
>> wrote:
>> >> 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).
>>
>> I'm not sure it's negligible.  It's 9 bits if the attacker can figure
>> out the stack alignment and 18 bits if the attacker can't.  This isn't
>> great, but it's far from nothing.
>>
>> >
>> > 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.
>> >
>>
>> If I see a real argument that randomizing the vdso like a library is
>> better than randomizing it separately but weakly, I'll gladly consider
>> it.  But the references I've seen (and I haven't looked all that hard,
>> and I'm not an memory exploit writer) are unconvincing.
>>
>> I'd really rather see a strong inter-mmap randomization scheme adopted.
>>
>> --Andy
>>
>> >
>> > --Hector Marco.
>> >
>> >
>> >
>>
>>
>>
>> --
>> Andy Lutomirski
>> AMA Capital Management, LLC
>
>
>
>
> --
> Regards,
> Reno Robert
> http://v0ids3curity.blogspot.in/
>
>



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