Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Programming Security Linux

How To Exploit NULL Pointers 139

Posted by kdawson
from the but-were-embarrassed-to-ask dept.
An anonymous reader writes "Ever wondered what was so bad about NULL pointer exceptions? An MIT Linux kernel programmer explains how to turn any NULL pointer into a root exploit on Linux. (There was also a previous installment about virtual memory and how to make NULL pointers benign.)"
This discussion has been archived. No new comments can be posted.

How To Exploit NULL Pointers

Comments Filter:
  • by Lord Grey (463613) * on Tuesday April 13, 2010 @04:03PM (#31838954)

    TFA is an extremely well-written, easy-to-follow tutorial. I "played along at home" (well, at work, actually) as the author recommended and exploited a system on the first try. Great stuff!

    Hang on, one of our SysAdmins wants to talk to me about something.

    BRB

  • Exceptons? (Score:5, Informative)

    by mccalli (323026) on Tuesday April 13, 2010 @04:10PM (#31839046) Homepage
    "Ever wondered what was so bad about NULL pointer exceptions?..."

    Nothing. Because if they're an exception, they've been safely caught by the platform's exception handling mechanism. This article isn't about exceptions, it's about dereferencing your actual raw NUL pointers themselves in languages that either don't have the exception mechanism or where it simply hasn't been used.

    Cheers,
    Ian
    • Re:Exceptons? (Score:5, Insightful)

      by shutdown -p now (807394) on Tuesday April 13, 2010 @04:19PM (#31839128) Journal

      Nothing. Because if they're an exception, they've been safely caught by the platform's exception handling mechanism. This article isn't about exceptions, it's about dereferencing your actual raw NUL pointers themselves in languages that either don't have the exception mechanism or where it simply hasn't been used.

      Actually, most JIT-based VMs don't do explicit null checks, but rather let the OS signal access violation (as it is supposed to be guaranteed for NULL pointers, unlike dangling or garbage ones), and if it happens, wrap it into the language-specific exception - it's much faster than explicit checks for every pointer dereference.

      • Re:Exceptons? (Score:5, Informative)

        by Chris Burke (6130) on Tuesday April 13, 2010 @04:47PM (#31839418) Homepage

        Besides, the article is actually about NULL pointer dereferences within the kernel, where niceties like language-based exception handling mechanisms are often hard to come by. So the language you write your application code is immaterial.

        Also not just any dereference will do, it has to be a function pointer dereference.

        And recent kernels have protection against mmap()ing page 0.

        However the author has a good point that both NULL function pointer calls in the kernel and hackers getting around the mmap() protection have happened before. So while you can't exactly exploit any Linux system using the procedure he describes (several critical components require you to already have root :P) it does sound like a weakness.

        • Re:Exceptons? (Score:4, Interesting)

          by Hurricane78 (562437) <deleted@@@slashdot...org> on Tuesday April 13, 2010 @05:16PM (#31839688)

          But then it is not an exploit, since the kernel always is root anyway.

          • Re:Exceptons? (Score:5, Informative)

            by Chris Burke (6130) on Tuesday April 13, 2010 @05:28PM (#31839804) Homepage

            But then it is not an exploit, since the kernel always is root anyway.

            As given, no the procedure is not a working exploit for any meaningful definition ("I'm teh 1337 hacks-zor! I r00ted my home desktop!")

            However, if you could identify a case where the kernel dereferenced a NULL function pointer, and if you could get around the kernel's mmap() protection (neither implausible), then you can get the kernel to run your code using its privilege level. Meaning you can get root for yourself. And then yes indeedy you have an exploit.

            • If you have the keys to the server room, and if you notice a post-it note with the root password, then yes indeedy you have an exploit.
              • by micheas (231635)

                If you have the keys to the server room, and if you notice a post-it note with the root password, then yes indeedy you have an exploit.

                Especially if you have an 18 wheeler and a fork lift.

            • by Yvanhoe (564877)
              As you point out, there is already a protection against that. I may ask, what is the point then ?
              • Re: (Score:3, Informative)

                by icebraining (1313345)

                If you had Wine installed in Ubuntu, the package would disable the protection to enable 16-bit Windows apps to run.

          • by shentino (1139071)

            It's an exploit of the kernel, not the application.

        • Besides, the article is actually about NULL pointer dereferences within the kernel, where niceties like language-based exception handling mechanisms are often hard to come by. So the language you write your application code is immaterial.

          Exception handling is immaterial anyway. It's not like you need language support for exceptions to check the value of an untrusted pointer against the NULL constant.

          And yes, it's nice to have your tools do that for you, but odds are that if you're that sloppy to begin with, it won't take you long to introduce a vulnerability that no language constraint or compiler/interpreter toolchain can catch.

          • Re: (Score:3, Interesting)

            by Chris Burke (6130)

            Exception handling is immaterial anyway. It's not like you need language support for exceptions to check the value of an untrusted pointer against the NULL constant.

            Yeah but constantly checking sucks, as does recovery.

            Personally I use the method described by the uh... GGP? The dude what I first replied to. Basically, I refrain from using root access to tell the OS to let me map page 0, and then refrain from mmap()ing page 0. Then I let the hardware detect the illegal access for me. =D

            • The "using root access to tell the OS to let me map page 0" bit was just to simulate a hypothetical situation were this the block about checking page 0 wasn't effective (there used to be a bug in recent kernels which allowed you to bypass this).

              The point of the article was not to hand you an exploit on a platter, but rather tell you how to leverage 2 kinds of bugs (1. bypassable mmap 0 protection, and 2. an unchecked null pointer dereference) into a root exploit.

              Bugs of both classes have existed multiple

        • Re:Exceptons? (Score:5, Insightful)

          by eparis (1289526) on Tuesday April 13, 2010 @06:20PM (#31840186)

          He demonstrates the simplest easiest to understand case, that of a NULL function pointer. But it really can extend to reads and writes of a NULL pointer as well (not always but often). If you can make the kernel read data from a NULL pointer you would be able to trick the kernel into reading a fake struct that you placed at NULL. Maybe that fake struct had a function pointer which you can easily set to another userspace address and voila, win. Maybe the code will read that struct and then write somewhere else in memory based on the information in that struct. Simply make that write happen in a place you choose which might lead to an eventual NULL function pointer.

          Any time the kernel accidentally dereferences a pointer (especially one outside of kernel space) and uses that data things can go bad. The mmap_min_addr checks were added to harden against the EXACT class of common bugs he describes and I'm saddened it was dismissed so out of hand.

          • by Chris Burke (6130)

            If you can make the kernel read data from a NULL pointer you would be able to trick the kernel into reading a fake struct that you placed at NULL.

            A pointer (that's NULL) pointing to a function, a pointer (that's NULL) pointing to a pointer to a pointer... It's all just pointer-chasing indirect function calls to me. :)

            The mmap_min_addr checks were added to harden against the EXACT class of common bugs he describes and I'm saddened it was dismissed so out of hand.

            Who dismissed it? The distros? The kernel d

        • Also not just any dereference will do, it has to be a function pointer dereference.

          The Null pointer doesn't have to be a function pointer. A pointer to a structure containing a function pointer would work too. Or a pointer to a structure that contains a pointer to another structure that will be changed. And many other situations as well. The only thing is, it will be (slightly) harder to exploit, but not impossible.

      • by Q2Serpent (216415)
        as it is supposed to be guaranteed for NULL pointers, unlike dangling or garbage ones

        Guaranteed by whom? I believe the C standard only guarantees undefined behavior. You seem to be suggesting that someone else is guaranteeing specific behavior.
        • C standard is irrelevant here, since we're talking about JIT compilers that directly produce native code for particular platform (i.e. CPU architecture + OS). In practically all modern platforms, a null pointer is guaranteed to be guarded by the OS, in a sense that dereferencing it is always a segfault (and never a garbage read or data corruption).

          If such a guarantee is in place - normally implemented by OS simply by reserving a page which no process can read/write - using it is free, and any extra checks w

          • Even that is no guarentee of safety.

            my_func(int foo[]) {
              foo[1024] = 0;
            }

            now, we call malloc to allocate some memory, then pass it to my_func not realizing it returned NULL, my_func happily overwrites the first word in the second page not generating a SEGFAULT as only the first page is unmapped to protect against NULL pointer dereferences.

            • Again, we aren't talking about C here. We're talking about JIT-compiled languages such as C# or Java, which are memory-safe. They don't have pointer arithmetic, so any reference either points to valid memory (a non-garbage-collected object), or it is null.

    • Re: (Score:3, Insightful)

      by sopssa (1498795) *

      it's about dereferencing your actual raw NUL pointers themselves in languages that either don't have the exception mechanism or where it simply hasn't been used.

      But if this gains you root access without you actually having it, it's a fault in the OS security. You cant rely on programming languages to protect against such methods.

      • Re: (Score:3, Insightful)

        by 0123456 (636235)

        But if this gains you root access without you actually having it, it's a fault in the OS security. You cant rely on programming languages to protect against such methods.

        Except you need root access in order to map page zero into your address space, and you generally need root access to configure the kernel so that it will allow root to map page zero into your address space (Wine in Ubuntu used to set the minimum mmap address to zero, I'm not sure whether it still does). So to get root access in this way you either need root access or multiple userspace vulnerabilities. And then you need a kernel flaw which executes code relative to a null pointer.

        So while it's interesting a

        • by prockcore (543967)

          Except you need root access in order to map page zero into your address space

          That's assuming there aren't any exploitable bugs that will allow you to map page zero. For example, a bug (that has since been fixed) existed where you could mmap a lot of memory and it would eventually fail and mmap page 0.

        • by Stray7Xi (698337)

          (Wine in Ubuntu used to set the minimum mmap address to zero, I'm not sure whether it still does)

          Okay that's scary. Seriously reenabling a known exploit is not a workaround any distro should be using. I checked my box and it was set to 0 with up to date karmic w/ wine, not anymore.

          • (Wine in Ubuntu used to set the minimum mmap address to zero, I'm not sure whether it still does)

            Okay that's scary. Seriously reenabling a known exploit is not a workaround any distro should be using. I checked my box and it was set to 0 with up to date karmic w/ wine, not anymore.

            I've ran across that, and it was never set by default. I think support for running 16-bit programs required it (and might still require, but most people wouldn't come across it). When you tried running it, it would give you a message that you needed to set the minimum mmap address to zero to get it to work, along with a message explaining that it was a bad idea to do so.

            • (Wine in Ubuntu used to set the minimum mmap address to zero, I'm not sure whether it still does)

              Okay that's scary. Seriously reenabling a known exploit is not a workaround any distro should be using. I checked my box and it was set to 0 with up to date karmic w/ wine, not anymore.

              I've ran across that, and it was never set by default. I think support for running 16-bit programs required it (and might still require, but most people wouldn't come across it). When you tried running it, it would give you a message that you needed to set the minimum mmap address to zero to get it to work, along with a message explaining that it was a bad idea to do so.

              Heh...nevermind, I'm wrong. Apparently that used to be the case in the beginning, now they place a script (/etc/sysctl.d/30-wine.conf) that sets it to zero by default. Grandparent was right, that's scary.

    • by marcansoft (727665) <hector@nOsPam.marcansoft.com> on Tuesday April 13, 2010 @04:30PM (#31839264) Homepage

      One of the many exploits that we've used to own the Wii (in fact, the very first runtime IOS exploit that we used, which I found and implemented) was a NULL pointer dereference bug, and it wasn't even a function pointer.

      I wrote a detailed blog post [hackmii.com] about it recently. The short version is that they doubly dereference a near-NULL address and write to it, and NULL happens to be real physical memory that we control (call it 'insecure', if you wil). The double dereference lets us direct the write anywhere, including the stack, and it's game over. That's the "usermode" exploit. Privilege escalation into the kernel is trivial because they have some huge kernel holes. The fact that they map the 'insecure' memory as executable (!) in every application makes it even easier.

      • Re: (Score:3, Insightful)

        by godrik (1287354)

        I recall wondering whether you were the marcan from team twiizer or not. I guess I am sure now.

        PS: you did an awesome job on the wii. thank you for it!

  • OS dependent (Score:4, Informative)

    by mdf356 (774923) <mdf356@g[ ]l.com ['mai' in gap]> on Tuesday April 13, 2010 @04:14PM (#31839076) Homepage

    This is very OS dependent.

    For example, on AIX on POWER, page 0 in both real and virtual addressing modes is readable by all and writable by none. So a read from a NULL pointer produces junk data (actually interrupt machine code) and a write is fatal.

    • Re:OS dependent (Score:5, Informative)

      by hrimhari (1241292) on Tuesday April 13, 2010 @04:43PM (#31839378) Journal

      Sorry to point out the redundancy, but the summary seems clear enough with its how to turn any NULL pointer into a root exploit on Linux .

    • Re: (Score:3, Interesting)

      by russotto (537200)

      So a read from a NULL pointer produces junk data (actually interrupt machine code) and a write is fatal.

      IIRC, the first two words of the AIX page 0 are 0xdeadbeef 0xbadfca11. Because of the way the AIX function pointers work, calling page 0 results in the PC being set to 0xdeadbeef and R2 to 0xbadfca11, and the register dump (for the misaligned PC) immediately tells you what you did wrong. (The reason AIX page 0 is readable is for a specific compiler optimization -- the case "if (foo && *foo)" an

      • by lgw (121541)

        There's likely no performance advantage to be had through "branch avoidance" in "if (foo && *foo)" - either way, you're branching if foo is NULL. Conditional branches that "fan out" are expensive, as the processor can only pipeline so many paths. Conditional branches that converge don't have this penalty, at least on a sensible chip (and from what I've heard, the POWER architecture doesn't suck).

        • by russotto (537200)

          The short circuit case is something like

          cmpi 0, foo ;; assuming foo is in a register
          beq elseclause
          ld r15, foo ;; r15 is arbitrary
          cmpi 0, r15
          beq elseclause


          The non-short-circuit case is something like
          ld r15, foo
          cmpi cr1, 0, foo
          cmpi cr2, 0, r15
          cror cr1,cr2 ;; condition register or
          beq cr1, elseclause

          In the non-short-circuit case, not only is one branch dropped (though a cror is added), but the compare of the pointer and the load of its contents overlap. The earlier POWER architectures didn't have speculative e

          • by lgw (121541)

            With current chips, it's difficult to predict performance because the chips ability to parallelize nearby instructions in the instruction stream is very complex. However, conditional branches are very expensive if you exceed the chip's ability to do speculative execution (which may be just 2 paths), because it disrupts all that good pipelining.

            In modern bit bashing, you see a lot of clever math tricks to avoid branches. I can remember whien division was to be avoided if at all possible, but now a trick th

    • The concept of a null pointer kernel vulnerability works in Windows too [microsoft.com].

      Like Linux, the NT kernel exists in the same address space as applications, so the same concepts apply. To map the null 64k of address space as valid memory, call either VirtualAlloc [microsoft.com] or MapViewOfFileEx [microsoft.com] (*). Passing NULL as your desired mapping address to these functions normally means that you want Windows to find an available virtual address for you. To get around that, pass (void*)1. This works because NT will round down to the ne

  • by NumberField (670182) * on Tuesday April 13, 2010 @04:19PM (#31839144)
    I was intrigued by the ./ posting, which claimed that the tutorial would show how to exploit any NULL pointer dereference. The actual article, however, requires a CALL to the NULL pointer. While some NULL pointer bugs are function pointers, many are not. Kernel code that merely reads or writes data to a NULL pointer will not be exploitable as shown.
    • I was intrigued by the ./ posting, which claimed that the tutorial would show how to exploit any NULL pointer dereference. The actual article, however, requires a CALL to the NULL pointer.

      For further context, see my whitepaper on how to turn any kdawson-posted Slashdot story into a NULL issue.

    • Re: (Score:3, Insightful)

      by Myria (562655)

      I was intrigued by the ./ posting, which claimed that the tutorial would show how to exploit any NULL pointer dereference. The actual article, however, requires a CALL to the NULL pointer. While some NULL pointer bugs are function pointers, many are not. Kernel code that merely reads or writes data to a NULL pointer will not be exploitable as shown.

      But sometimes, they can still be exploited. Let's hypothesize a UNIX clone whose kernel has this code in its implementation of the chroot() system call, something that only root should be able to call:

      /* deny access unless they're root */
      if (get_current_process()->m_uid != 0)
      {
      return EPERM;
      }

      Now let's suppose that there is a bug in the kernel that you can exploit to cause get_current_process() to return a null process pointer. Using mmap(), you can allocate the zero page. The get_curren

    • It might not work with all NULL pointer dereferences, but it definately works with more than just function pointers.

      Here [hackmii.com] is one example how to exploit a different kind of NULL pointer dereference.

      The article is rather long, but the short summary is, the kernel does a->some_field->x=NULL , where a is the NULL pointer.

      The NULL page is under the control of the exploiter. So he can set some_field to point to a memory location he wants to zero out. That could be any location in kernel space (such as a h

    • by spitzak (4019)

      The article was trying to show a simple example.

      I think a far more common exploit would be to place a copy of a structure the kernel expects to reference at 0 and trigger some bug so it uses a null pointer to such a structure. If that structure contains a pointer to a function that the kernel calls you put the pointer to your code there. Probably more likely the structure just contains a pointer to some location the kernel will write, you change this to point at something in the kernel you want to overwrite

  • from the article

    For various reasons, that that’s not quite how it works. It turns out that switching between address spaces is relatively expensive, and so to save on switching address spaces, the kernel is actually mapped into every process’s address space, and the kernel just runs in the address space of whichever process was last executing.

    I thought the BigMem kernel patches a few years back put the kernel in it's own VM, with minimal copying into userspace VM space, or am i missing something

    • Yeah, shouldn't switch be easily take care of by a base register?
      • by Chris Burke (6130) on Tuesday April 13, 2010 @04:59PM (#31839526) Homepage

        Yeah, shouldn't switch be easily take care of by a base register?

        Well it is. On x86 systems, the intuitively named Control Register 3 is a pointer to the base of the page tables. From a software point of view, switching address spaces is as easy as writing CR3.

        From a hardware point of view, that act has additional implications. You have to flush the TLBs, which sucks royal if it happens on every system call. If you have linearly tagged caches (or any other linearly tagged structure) then you'll have to flush those too. There are ways to partially mitigate these effects, but since you can't rely on them being there it's best to just avoid CR3 writes as much as possible -- which means there's less reason to implement the necessary widgets.

    • Re: (Score:3, Interesting)

      by Chris Burke (6130)

      I thought the BigMem kernel patches a few years back put the kernel in it's own VM, with minimal copying into userspace VM space, or am i missing something?

      I don't know what that patch did (BigMem implies something like using 2MB pages, but what's in a name?), but I do know that the author is right about address space switches being expensive and not something you'd want to do on every system call, or any system call that is expected to return control to the same process for that matter.

      In practice I don't

      • Why should a change of the page table be needed? All you need are separate segments for kernel and user mode. Since pointers are relative to the corresponding segment, the kernel segment address 0 would be completely different from the user mode address 0 (and should be in reserved kernel space).

        • by 0123456 (636235)

          Why should a change of the page table be needed? All you need are separate segments for kernel and user mode.

          For a start, because code segments no longer exist in x86_64.

        • Re: (Score:3, Informative)

          by Chris Burke (6130)

          Why should a change of the page table be needed?

          It's not needed if you map your kernel into the application's page tables. ;)

          All you need are separate segments for kernel and user mode.

          1) Segmentation is essentially non-existent* in 64-bit mode.
          2) Segmentation sucks. Always has, always will. That's why even in 32-bit mode most segments are made with base 0 and max limit, and processors are optimized for this case.
          3) Okay, so you switch your CS and DS segments when you go into kernel mode (well actually you

  • Bad summary (Score:5, Insightful)

    by ElMiguel (117685) on Tuesday April 13, 2010 @04:21PM (#31839154)
    As usual, bad summary. TFA explains how to exploit a theoretical kernel bug that happens to "read a function pointer from address 0, and then call through it". That's a long shot from turning "any NULL pointer" into a root exploit as the summary claims.

    To be honest, I'm not sure why I bothered writing this comment. If the editors themselves don't care about the accuracy of the stories, why should I?

    • Well, if the hacker put his function at address 0, to deference any NULL pointer would effectively be calling that function, assuming this memory mapping really works.
    • Re:Bad summary (Score:5, Insightful)

      by BJ_Covert_Action (1499847) on Tuesday April 13, 2010 @04:40PM (#31839350) Homepage Journal

      If the editors themselves don't care about the accuracy of the stories, why should I?

      Because you're not kdawson, and that's something to be proud of. ;)

    • Yep, this is how it's been with pretty much all /. articles that link to ksplice. The articles are second rate almost everytime, but they attempt to pass it off as revelation.

    • TFA explains how to exploit a theoretical kernel bug that happens to "read a function pointer from address 0, and then call through it". That's a long shot from turning "any NULL pointer" into a root exploit as the summary claims.

      Having the NULL pointer being a function pointer was just the easiest "use case" for this kind of bug.

      For another example, involving a write to a doubly dereferenced NULL pointer, read here [hackmii.com].

      And, with most structures containing pointers to other structures, double dereferencing doesn't look so far-fetched.

  • It turns out that switching between address spaces is relatively expensive, and so to save on switching address spaces, the kernel is actually mapped into every process's address space, and the kernel just runs in the address space of whichever process was last executing.

    So a CPU design bug propagated its way into OS architecture, leading to a security hole.

    Intel never really got the crossing of privilege domains right. Context switching is too slow, call gates aren't very useful, and the segmented m

    • by Chris Burke (6130)

      It's not about changing privilege levels, it's about changing address spaces, which is a costly operation in any architecture.

      • by Animats (122034)

        it's about changing address spaces, which is a costly operation in any architecture.

        Not necessarily. On some of the SPARC machines, it's relatively cheap, because there's a separate set of registers for each protection level.

        • by Chris Burke (6130)

          Not necessarily. On some of the SPARC machines, it's relatively cheap, because there's a separate set of registers for each protection level.

          On a typical system call you really only need to save the registers you use just like in a normal function call so it's relatively cheap in x86 too. Though it's hardly instantaneous to change privilege levels. I can certainly believe you when you say SPARC does this faster. But that's not what we're talking about.

          We're talking about changing the Page Table Base Regis

      • Re: (Score:3, Interesting)

        by ArsenneLupin (766289)

        changing address spaces, which is a costly operation in any architecture.

        Not necessarily. What if Intel had real segments, pointing each to a separate address space rather than just being windows into a same global address space.

        In a perfect world, each segment would have its own CR3 (page table root), and it would not only be more secure, but also more performant (no flushing of kernel's TLB cache when switching from one process to the other), and would have allowed better "big memory" support under 32 bit systems.

  • Does anyone remember sending a link in AIM as file:||null\null\null? does null points?
  • You're gonna blow the best source of income some folks have. Nothing like an OS its operator thinks is "secure"....
    • Re: (Score:2, Insightful)

      by maxwell demon (590494)

      Well, if you read the article, you'll find out that you have to
      * circumvent the protection against mmap to address 0 (in the article, that one was just done as root)
      * get the kernel to call a function through a function NULL pointer (that's what was done through the special kernel module)

      Since the exploit doesn't make much sense if you already are root, for this exploit you have to
      * find an existing bug in the kernel which allows you to circumvent the mmap protection.
      * find another existing bug in the kerne

      • Re: (Score:2, Interesting)

        by gman003 (1693318)

        Considering that null function pointer bugs are a dime a dozen on any system, finding one of those is easy. TFA also points out that the mmap protection code in Linux has been historically weak, although there don't seem to be any open bugs at the moment.

        So the article could have been better titled as "Why null function pointer bugs are serious business", but "How to exploit null [function] pointers" is still pretty accurate.

  • by Alex Belits (437) * on Tuesday April 13, 2010 @04:48PM (#31839436) Homepage

    If you have a bug in kernel code that causes NULL pointer dereference, it can be used for various nastiness (in this case, privilege escalation).

    This is why kernel shouldn't do it, and this is why it was an actual kernel bug that was exploited by so-called NULL pointer exploits. This is why those bugs were fixed.

    Apparently some readers have an impression that what was posted is an actual exploit that works on a current kernel by dereferencing NULL pointer in userspace. In reality it relies on a buggy module being introduced, so kernel NULL dereference can be triggered by the user.

  • Sorry, but if anything that simple can cause root access, then that’s a general error of the architecture and kernel. An OS should expect every app and every data input source to cause maximum mayhem in the system. And start from that point.

    On in other words: Get SElinux, or an equivalent system (RSbac+more?)!

    • by 0123456 (636235) on Tuesday April 13, 2010 @05:14PM (#31839660)

      Sorry, but if anything that simple can cause root access, then that’s a general error of the architecture and kernel.

      By default you need root access (or an exploitable bug) to map page zero into your address space, and you need to specifically configure the kernel to allow it, and then you need an exploitable kernel bug to make use of it.

      I wouldn't exactly call that 'simple'.

  • get a null pointer to exploit ME

    ooooohhhhhhhh

  • rats, doesn't work. you guys lie.

  • Ok, kids, it's code review time! What's wrong with the following code? :)

    #include <sys/mman.h>
    #include <stdio.h>
    #include <fcntl.h>

    int main() {
    mmap(0, 4096, PROT_READ|PROT_WRITE,
    MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, -1, 0);
    int fd = open("/sys/kernel/debug/nullderef/null_read", O_WRONLY);
    write(fd, "1", 1);
    close(fd);

    printf("Triggered a kernel NULL pointer dereference!\n");
    return 0;
    }

  • In the author's article about how to map the NULL pointer [ksplice.com], there's this caveat:

    Note that most modern systems actually specifically disallow mapping the NULL page, out of security concerns. To run the following example on a recent Linux machine at home, you'll need to run # echo 0 > /proc/sys/vm/mmap_min_addr as root, first.

    So under normal circumstances, even with a NULL dereference in the running kernel, this method would not allow you to gain root privileges.

    My question is, what legitimate reason m

  • by heli_flyer (614850) on Tuesday April 13, 2010 @07:12PM (#31840554)
    This is not "how to exploit NULL pointers" ... this is "how to exploit a kernel NULL function pointer". Well, duh. In other news, security researches find exploit for systems with blank root password.
    • Re: (Score:3, Informative)

      by ArsenneLupin (766289)

      This is not "how to exploit NULL pointers" ... this is "how to exploit a kernel NULL function pointer".

      No, it's just the "simplest" example of exploiting NULL pointers. If your NULL pointer is not a function pointer, you can still exploit it in many cases, you just need to work slightly harder [hackmii.com].

  • by Anonymous Coward

    ...as far as I can tell is simply to ban null pointers in the kernel.

    I've done alot of development in my time and I've never needed to point at null.

  • The correct term is null pointer (no all-caps). It's a combination of the words null and pointer. In the C and C++ languages, a few of the standard headers define a macro named NULL to a value that can be used as a null pointer in those languages.

    On a related note, I sometimes see people talking about a MACRO. Same thing, the word is macro, and there's a common convention of naming macros in all-caps; the term macro itself shouldn't be in all-caps. Same goes for camel case and all-caps; even though these

  • The original Multics design for virtual memory and dynamic linking & loading, from which Unix and Linux derive, relied on pointer fault handling to distinguish different stages of linking. People already understood these vulnerabilities in the 1950s, folks. We should regard this crap as ancient history because we could be standing on the shoulders of giants, if only a generation of know-nothings (Gates, I'm looking at *you*) hadn't blithely ignored most of the lessons already learned.
  • The summary is a bit broad. TFA is good, but is limited to cases where you can exploit a weakness to get a page mapped at address 0 and then exploit another kernel bug to get it to call to address 0 (not simply read or write). IF you can manage that and IF you know exactly where things are in the running kernel, THEN you have a root exploit. That's not to say it isn't a problem, just that it's far from ANY NULL pointer dereference.

"Hey Ivan, check your six." -- Sidewinder missile jacket patch, showing a Sidewinder driving up the tail of a Russian Su-27

Working...