Re: PIE bypass using VDSO ASLR weakness - Linux kernel

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > Given that ASLR is not effective in VDSO and comes down to 11 quality bits
> > as per pax test making return-to-vdso feasible even for PIE binary, whether
> > this should be considered as a bug and CVE be assigned?

> Yes, we can proceed to CVE assignment. The more recent discussion
> hasn't been on oss-security with, for example:
>
>    
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso&id=bc3b94c31d65e761ddfe150d02932c65971b74e2
>    http://marc.info/?l=linux-kernel&m=141911002822659&w=2

> This apparently mentions both the original discovery:
>
>    The current algorithm is buggy: the vdso has about a 50%
>    probability of being at the very end of a PMD.

Use CVE-2014-9585 for this vulnerability, which corresponds to a
portion of the above bc3b94c31d65e761ddfe150d02932c65971b74e2 patch.

(not yet available at
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/x86/vdso/vma.c)
 
> and a second discovery that was made separately:
>
>    The current algorithm also has a decent chance of failing outright
>    due to incorrect handling of the case where the top of the stack is
>    near the top of its PMD.
>
> Here, our question, for anyone, is: is there a security impact from
> the "failing outright" outcome? Or is there only a performance impact
> (e.g., any correctly written application will continue to work, but
> will not benefit from any vDSO functionality)?

We haven't seen any responses. There is currently no CVE ID for this
"incorrect handling of the case where the top of the stack is near the
top of its PMD" issue. This incorrect-handling issue is not within the
scope of CVE-2014-9585.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJUr/73AAoJEKllVAevmvmssroIALsU2TwXIFvU4tJsoeUUeIos
8FR8zKml9mta0lYjp3gC6fFH0JCB7wNz8D/euFjci2u5pTvCM68YYYgAWKySfg5I
SvvZz6NtAhA642odtQEB25QQN47RizdP2uduze4q5BUTGQu65v8m4pL5GWOFfeMj
MrvK4Zqu7KFrZgkfBU+utNplhFeYE0hCVmPdY5EvIRs0vEB7vlW2JoDe62OGjySA
r6AGxWFzL2cgjhGJn/crOBcb1eOq4Xl0YY/UENIroOXQTxdNvuUUkQyw+6O+wCzM
vUmyGpOq5c+l6EbDF5I+pfPgyjnyDaSMTdmtJkW9nFauP/95QzCKVMiUWR8paU4=
=EWmq
-----END PGP SIGNATURE-----