[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.00.1302280123380.30582@twin.jikos.cz>
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.
