Dailydave mailing list archives
Re: On exploiting null ptr derefs, disabling SELinux, and silently fixed Linux vulns
From: Sebastian Krahmer <krahmer () suse de>
Date: Tue, 6 Mar 2007 10:28:41 +0100 (CET)
On Mon, 5 Mar 2007, Michal Zalewski wrote: Although its not a classic NULL ptr dereference; its a function-ptr thingie; you can exploit NULL ptr dereferences: **ptr = value; that can happen in more places you first think of. And if ptr is NULL, you have your real NULL ptr exploit. Sebastian
On Mon, 5 Mar 2007, TINNES Julien RD-MAPS-ISS wrote:So, to exploit "to-userland pointer dereference" class of kernel flaws, you just have to mmap() the page at the correct address (and mmap at 0 is perfectly allowed). [...] I don't understand you here. The bug spender has mentioned is afair, exactly a null pointer dereference.You're not exploiting any userland application (the code being run is your own program, you already have a full control of it), correct? You're attacking the kernel. The flaw in kernel is not caused by a null pointer dereference (the kernel is not vulnerable because of trying to read or write *0x0 - that's what a dereference is). The flaw is caused by a missing check that allows you to gain access to the first physical page of memory, which you can then read or write. So a proper title would be "on exploiting missing checks" or "on gaining access to *0x0". Note that Brad's exploit doesn't even get to access 0x0 in process's address space - he just gets an instance of physical page 0 mapped to some sane address. Yeah, it's just semantics, but the issue is important in that we do not want crashes caused as userland NULL pointer dereferences to be considered exploitable by those who misinterpret the nature of this flaw.http://cansecwest.com/core05/memory_vulns_delalleau.pdfYeah, seen that presentation in person. That's a wholly different class of problems, and I did mention it in my initial response (some architectures, and some large-offset operations on NULL ptr tables or structures, are vulnerable; NULL ptr derefs as such usually aren't). /mz _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
-- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer () suse de - SuSE Security Team ~ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- Re: On exploiting null ptr derefs, disabling SELinux, andsilently fixed Linux vulns, (continued)
- Re: On exploiting null ptr derefs, disabling SELinux, andsilently fixed Linux vulns TINNES Julien RD-MAPS-ISS (Mar 05)
- Re: On exploiting null ptr derefs, disabling SELinux, andsilently fixed Linux vulns don bailey (Mar 05)
- Re: On exploiting null ptr derefs, disabling SELinux, andsilently fixed Linux vulns Thomas Ptacek (Mar 05)
- Re: On exploiting null ptr derefs, disabling SELinux, and silently fixed Linux vulns Michal Zalewski (Mar 05)
- Re: On exploiting null ptr derefs, disabling SELinux, and silently fixed Linux vulns Dave Korn (Mar 06)
- (windows is vulnerable too) & final comments on naming Brad Spengler (Mar 07)
- Re: (windows is vulnerable too) & final comments on naming intropy (Mar 07)
- Re: (windows is vulnerable too) & final comments on naming Dave Aitel (Mar 07)
- Re: On exploiting null ptr derefs, disabling SELinux, and silently fixed Linux vulns Joel Eriksson (Mar 07)
- Message not available
- Re: On exploiting null ptr derefs, disabling SELinux, and silently fixed Linux vulns Dave Korn (Mar 14)
- Re: On exploiting null ptr derefs, disabling SELinux, and silently fixed Linux vulns Sebastian Krahmer (Mar 06)