VDSO randomization not very random

VDSO randomization not very random

[Hanno Böck]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

Hello,

I already reported this into your bugzilla, however Greg KH told me it
might be a better idea to post it here:

With current Linux kernels it seems the address randomization for
loading the vdso library is not that random and can easily be
bruteforced.

This can easily be demonstrated. Get libvdso address from one
executable:
$ ldd /usr/bin/less|grep vdso
	linux-vdso.so.1 (0x00007fff73bfe000)

Now run ldd mutliple times and check if the same address appears:
c=0; while (true); do let c=c+1; ldd /usr/bin/less|grep
0x00007fff73bfe000; [ "$?" == 0 ] && echo $c; done

It usually takes only a few seconds and around 1000-2000 tries until
the loading address is repeated (note that results may vary, it seems
the randomization is biased, some values repeat more often than others).

This information is mostly from this blog entry:
http://v0ids3curity.blogspot.in/2014/12/return-to-vdso-using-elf-auxiliary.html
And here's a thread on oss-security discussing the issue:
http://www.openwall.com/lists/oss-security/2014/12/09/10

The latest version of paxtest added a check for this that guesses the
randomness of vdso:
https://grsecurity.net/~spender/paxtest-0.9.13.tar.gz $ ./randvdso 
VDSO randomisation test                  : 11 quality bits (guessed)

Bugzilla entry:
https://bugzilla.kernel.org/show_bug.cgi?id=89591

cu,
-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: VDSO randomization not very random

[Kees Cook]

Hi Hanno,

On Thu, Dec 11, 2014 at 10:45:01PM +0100, Hanno Böck wrote:
> Hello,
> 
> I already reported this into your bugzilla, however Greg KH told me it
> might be a better idea to post it here:
> 
> With current Linux kernels it seems the address randomization for
> loading the vdso library is not that random and can easily be
> bruteforced.
> 
> This can easily be demonstrated. Get libvdso address from one
> executable:
> $ ldd /usr/bin/less|grep vdso
> 	linux-vdso.so.1 (0x00007fff73bfe000)
> 
> Now run ldd mutliple times and check if the same address appears:
> c=0; while (true); do let c=c+1; ldd /usr/bin/less|grep
> 0x00007fff73bfe000; [ "$?" == 0 ] && echo $c; done
> 
> It usually takes only a few seconds and around 1000-2000 tries until
> the loading address is repeated (note that results may vary, it seems
> the randomization is biased, some values repeat more often than others).
> 
> This information is mostly from this blog entry:
> http://v0ids3curity.blogspot.in/2014/12/return-to-vdso-using-elf-auxiliary.html
> And here's a thread on oss-security discussing the issue:
> http://www.openwall.com/lists/oss-security/2014/12/09/10
> 
> The latest version of paxtest added a check for this that guesses the
> randomness of vdso:
> https://grsecurity.net/~spender/paxtest-0.9.13.tar.gz $ ./randvdso 
> VDSO randomisation test                  : 11 quality bits (guessed)
> 
> Bugzilla entry:
> https://bugzilla.kernel.org/show_bug.cgi?id=89591

I'm hoping this will get addressed as part of the discussion around
the "ASLRv3" patches. PIE (as well as VDSO) randomization has been a
per-arch implementation, and it would be best to unify this in a common
high-entropy solution.

I think the problem with VDSO right now is that it is randomized in
relationship to the stack, rather than being randomized on its own.

-Kees

-- 
Kees Cook
Chrome OS Security

Re: VDSO randomization not very random

[Andy Lutomirski]

On Thu, Dec 11, 2014 at 2:02 PM, Kees Cook <keescook@chromium.org> wrote:
> Hi Hanno,
>
> On Thu, Dec 11, 2014 at 10:45:01PM +0100, Hanno Böck wrote:
>> Hello,
>>
>> I already reported this into your bugzilla, however Greg KH told me it
>> might be a better idea to post it here:
>>
>> With current Linux kernels it seems the address randomization for
>> loading the vdso library is not that random and can easily be
>> bruteforced.
>>
>> This can easily be demonstrated. Get libvdso address from one
>> executable:
>> $ ldd /usr/bin/less|grep vdso
>>       linux-vdso.so.1 (0x00007fff73bfe000)
>>
>> Now run ldd mutliple times and check if the same address appears:
>> c=0; while (true); do let c=c+1; ldd /usr/bin/less|grep
>> 0x00007fff73bfe000; [ "$?" == 0 ] && echo $c; done
>>
>> It usually takes only a few seconds and around 1000-2000 tries until
>> the loading address is repeated (note that results may vary, it seems
>> the randomization is biased, some values repeat more often than others).
>>
>> This information is mostly from this blog entry:
>> http://v0ids3curity.blogspot.in/2014/12/return-to-vdso-using-elf-auxiliary.html
>> And here's a thread on oss-security discussing the issue:
>> http://www.openwall.com/lists/oss-security/2014/12/09/10
>>
>> The latest version of paxtest added a check for this that guesses the
>> randomness of vdso:
>> https://grsecurity.net/~spender/paxtest-0.9.13.tar.gz $ ./randvdso
>> VDSO randomisation test                  : 11 quality bits (guessed)
>>
>> Bugzilla entry:
>> https://bugzilla.kernel.org/show_bug.cgi?id=89591
>
> I'm hoping this will get addressed as part of the discussion around
> the "ASLRv3" patches. PIE (as well as VDSO) randomization has been a
> per-arch implementation, and it would be best to unify this in a common
> high-entropy solution.
>
> I think the problem with VDSO right now is that it is randomized in
> relationship to the stack, rather than being randomized on its own.
>

As far as I'm concerned, the vdso can go wherever the kernel wants to
put it, so long as it doesn't conflict with any real-world non-PIE
binaries.

--Andy

> -Kees
>
> --
> Kees Cook
> Chrome OS Security



-- 
Andy Lutomirski
AMA Capital Management, LLC