Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 28 Feb 2013 01:31:56 +0100 (CET)
From: Jiri Kosina <jikos@...os.cz>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request - Linux kernel: VFAT slab-based buffer
 overflow

On Wed, 27 Feb 2013, Greg KH wrote:

> > > If you know of any other ways that we can do this, please let us know.
> > 
> > - W^X
> 
> I thought we tried this, and had to revert it due to problems it caused
> with some dyanmic code generators.  Or am I totally mistaken here?

Userspace is problematic in this respect, agreed (because of all the JIT 
stuff, for example).

I am speaking more in terms of kernel now. I.e. having clear separation of 
kernel RO-data and kernel code. Basically what grsecurity/PAX is doing 
with their CONFIG_PAX_KERNEXEC, but with hardware support whenever 
possible (i.e. minimizing runtime performance penalty).

> > - not letting kernel dereference userspace pointers (and PMAP is not 
> >   available everywhere, unfortunately)
> 
> What do you mean by this?

If you trick kernel into derefereing pointer outside it's mapped space 
(i.e. address lower than TASK_SIZE, thus fully controller by potentially 
evil userspace), it'll happily do that (modulo incomplete 
counter-measures, such as vm.mmap_min_addr sysctl).

Thanks,

-- 
Jiri Kosina

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.