oss-sec mailing list archives



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

Attachment: signature.asc

Description: Digital signature

By Date By Thread

Current thread: