[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170418123713.GA5756@grsecurity.net>
Date: Tue, 18 Apr 2017 08:37:13 -0400
From: Brad Spengler <spender@...ecurity.net>
To: oss-security@...ts.openwall.com
Subject: Re: Silently (or obliviously) partially-fixed
CONFIG_STRICT_DEVMEM bypass
BTW, forgot I had posted this 8 years ago:
https://lwn.net/Articles/330488/
Since I always reveal hashes at the proper time:
spender@www:~$ ls -al devmem
-rw-r--r-- 1 spender spender 161 Apr 27 2009 devmem
spender@www:~$ cat devmem
there exist paging structures within the first 1MB of /dev/mem which can
be modified to thereby modify arbitrary memory and bypass any
restrictions on /dev/mem
spender@www:~$ md5sum ./devmem
6c8eb1e89e3e1a8c3bb207eecc517a20 ./devmem
spender@www:~$ sha1sum ./devmem
570b82139714e6640b9b1af02060e51de0558a9c ./devmem
Of course, it's unlikely anyone upstream figured out the above so I'm being
overly generous here. Enjoy it while it lasts Greg ;)
-Brad
On Mon, Apr 17, 2017 at 09:09:29AM +0200, Greg KH wrote:
> On Sun, Apr 16, 2017 at 04:25:38PM -0400, Brad Spengler wrote:
> > Hi all,
> >
> > I wanted to provide some small notice of upstream kernel developers silently
> > or obliviously partially fixing a CONFIG_STRICT_DEVMEM bypass which explicitly has
> > never been possible in grsecurity in the past 15 years. I say this because the commit
> > message makes no mention of this partially fixing a CONFIG_STRICT_DEVMEM bypass (and I
> > suppose a Secure Boot bypass, but what isn't these days?), and similarly makes no
> > mentions of the modifications it makes to the write side. CONFIG_STRICT_DEVMEM exists
> > to prevent userland from directly modifying kernel memory, yet the kernel will happily
> > make slab allocations in allowed regions below 1MB. CONFIG_STRICT_DEVMEM explicitly
> > allowed both reads and writes to these allocations. As noted, the commit below doesn't
> > fix the mmap side.
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4866aa812518ed1a37d8ea0c881dc946409de94
> >
> > Feel free to look at GRKERNSEC_KMEM code going back to 2002 in our 2.4.20
> > patch, or when it changed in 2003 for 2.4.21, or this explicit hunk, comment and
> > all, that's been around ever since CONFIG_STRICT_DEVMEM was added in 2008:
> >
> > +#ifdef CONFIG_GRKERNSEC_KMEM
> > + /* throw out everything else below 1MB */
> > + if (pagenr <= 256)
> > + return 0;
> > +#endif
> >
> > <additional comments/details removed: b76e178e7b24f238ba0dd70104336298f493f0142056a1e5f35c27897369adc6>
> >
> > While I'm here, some more VMAP_STACK fallout (DoS/potential memory corruption,
> > adding to the dozen or so posted earlier):
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=67b0503db9c29b04eadfeede6bebbfe5ddad94ef
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=606142af57dad981b78707234cfbd15f9f7b7125
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f190e3aec212fc8c61e202c51400afa7384d4bc
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=005145378c9ad7575a01b6ce1ba118fb427f583a
> > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=3b30460c5b0ed762be75a004e924ec3f8711e032
> > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=c919a3069c775c1c876bec55e00b2305d5125caa
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c4baad50297d84bde1a7ad45e50c73adae4a2192
> > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=5593523f968bc86d42a035c6df47d5e0979b5ace
> > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=7926aff5c57b577ab0f43364ff0c59d968f6a414
> > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=2d6a0e9de03ee658a9adc3bfb2f0ca55dff1e478
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7a7b5df84b6b4e5d599c7289526eed96541a0654
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8e9faa15469ed7c7467423db4c62aeed3ff4cae3
>
> Thanks a lot for the heads up, I'll work on queueing up the first commit
> you posted here for the next stable releases, and go through this list
> to ensure I caught all of these as well.
>
> Many thanks for letting us all know!
>
> greg k-h
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.
