[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 23 Jun 2017 20:50:03 -0400
From: Brad Spengler <spender@...ecurity.net>
To: oss-security@...ts.openwall.com
Cc: torvalds@...ux-foundation.org, pageexec@...email.hu
Subject: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an
ignored Secure Boot bypass / rootkit method
I know this is no longer the place to request CVEs, but CVEs should be
allocated for the following issues (this is in addition to the two dozen
or so already allocated for CONFIG_VMAP_STACK):
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=b05c73bd1e3ec60357580eb042ee932a5ed754d5
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=942a48730faf149ccbf3e12ac718aee120bb3529
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=942a48730faf149ccbf3e12ac718aee120bb3529
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0bd193d62b4270a2a7a09da43ad1034c7ca5b3d3
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=628c2893d44876ddd11602400c70606ade62e129
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5165da5923d6c7df6f2927b0113b2e4d9288661e
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9ff56ac352446f55141aaef1553cee662b2e310
Given my recent blog post mentioning CONFIG_VMAP_STACK:
https://grsecurity.net/an_ancient_kernel_hole_is_not_closed.php
I believe a CVE should also be allocated to it due to failing to handle
VLAs (which as I've noted have been exploited in the past in the kernel)
and is being marketed as a stack overflow prevention equivalent to what's
present in grsecurity (which it is not).
Here's a fix for a UAF introduced by upstream's refcount_t work (aka introducing
the vulns the defense is supposed to prevent, and it won't be the last):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=92347cfd62c174ab91ad97dd4bfbaa1d4aa28e67
Also, over two months ago I mentioned a CONFIG_STRICT_DEVMEM bypass that
still required fixes to the mmap side:
http://seclists.org/oss-sec/2017/q2/76
As predicted, everyone ignored the comment about the mmap side and fixes
were only committed and backported to stable kernels for the read/write
side. Thus the Secure Boot bypass still exists today, over two months later
in all upstream kernels -- a CVE should be allocated for this separate issue
as well.
Also a shout out to Linus for his recent trade disparagement:
https://www.spinics.net/lists/kernel/msg2540934.html
It's big talk coming from a guy who hasn't protected his users for the past
16 years, who authored the broken stack gap patch that crashed machines and
broke apps in 2010 and introduced the userland ABI changes that are now causing
problems with the proper fix (that oh, surprise, looks a lot like PaX's fix
from 2010). We've heard these kinds of nonsense claims from Linus before,
like here:
https://lkml.org/lkml/2011/6/6/306
Maybe someone pointed him to it and the embarrassment from realizing he was
completely wrong was too much that he's decided to lash out?
Yes Linus, our patches are such garbage the KSPP can't manage to do anything
other than copy+paste from them, and you're slowly merging them (along
with our registered copyrights). How do our table scraps taste?
BTW, we're happy to go toe-to-toe with you here in public on actual facts
instead of pathetic ad hominems.
-Brad
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
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.
