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.

SELinux was not the cause of any of the recent kernel exploits making use of NULL pointer dereference. For this class of bugs SELinux systems were stronger than non-SELinux systems when the attack was coming from a network facing daemon, but were weaker for logged in authenticated users. So for the purposes of this discussion (logged in users clicking things they shouldn't) Yes, older SELinux systems might be weaker than non-selinux systems. But SELinux was never the actual problem, just made the real problems harder or easier to exploit (in current kernels SELinux is believed to be stronger against both classes of attacks for these types of bugs)

Most people expect that dereferencing a NULL pointer will result in some sort of fault. If you map the virtual page 0 and then do this you don't get a fault. Remember that NULL==0.
mmap(0, ..., MAP_FIXED...
char *p = NULL;
*p = 'a';

address 0 now contains the letter 'a' and the program does not fault.

The idea is that if you do the mmap in userspace, fill that area with specially crafted information, then cause the kernel to hit a bug in the software (in this case a pipe) which dereferences a NULL pointer, you can make it operate on data you control. This is due to the fact that userspace and kernel operate in the same virtual address space. Sometimes (often?) this means you can take over the box.

mmap_min_addr tries to address this problem by disallowing a program from mapping the low virtual address space. That means it ONLY affects the class of bugs that involve a NULL pointer. If it's a corrupt pointer instead a NULL pointer mmap_min_addr is totally useless. For either class of bugs hardware segmentation could help. It wouldn't be a security panacea, but it would eliminate the need for the specific hacks which both Linux and BSD use.

My understand in a short and simple answer: before the x86_64 architecture revolution it was possible to effectively have a separate virtual memory space for the kernel and userspace. With x86_64 segmentation was removed.

Intel i686 processors had a pretty big performance hit if you used functionality since there was a TLB flush on every kernel trap. I don't believe many kernels made use of it. The PaX security patch set could and Red Hat's 4g/4g split kernels did (RH called them hugemem kernels, although I don't suggest them to anyone as they had their own issues.) The AMD Opteron processors actually had tagged TLBs so they didn't have to flush and performance didn't suffer nearly as badly.

In any case, with x86_64 that ability is simply gone. SPARC is often named as an architecture which doesn't suffer from this specific class of bugs since it always had completely separate kernel space and userspace virtual memory. I heard rumour their might be a brilliant solution that will hopefully come from the PaX/grsecurity team, but I don't believe anything has materialized just yet.

A patched kernel will fix this particular bug, but as long as wine is installed and mmap_min_addr is being set to 0 you have no protections for the next bug. Unless wine can be changed (which some smart people have told me it can't), there's nothing you can do except accept a higher security risk on your system.

Here's a fun tag line, "Windows applications can even make Linux less secure!"

Installing the wine package on ubuntu automatically sets mmap_min_addr to 0. The default install will have it set higher. Solution, remove wine.

No, this isn't the same bug. People confuse two issues. I wrote the mmap_min_addr protections to try to mitigate the effects of a certain class of common kernel bugs which exist because of design choices by Intel. That class of bugs can be summed up as NULL pointer usage. Every time someone finds a new NULL pointer usage bug we get the same story. RHEL (and any system with SELinux enabled) did not have protections for mapping the 0 page by local authenticated users, but did have protections for network facing daemons and the like. Other distros had protections for the local authenticated user but weaker protections for network facing daemons. The mmap_min_addr protections have since been enhanced in SELinux systems such that they have stronger protections, both for local authenticated users and for network facing daemons. My old comments from the first time this came up are at http://eparis.livejournal.com/

But the key to remember is that mmap_min_addr implementation is not the bug that allows elevation of privilege. In this case it was a very very old bug in the implementation of pipes. Previously Spender and friends have found bugs in performance counters (one which was actually much worse as it didn't fit into the very narrow class which might be mitigated by mmap_min_addr), in network sockets, and other places. These are the bugs which cause this to be a new story. Once he finds the real bugs he applies some of the same basic techniques (plus a whole lot of thought) to create an exploit. If the Linux kernel was bug free we wouldn't need mmap_min_addr. If mmap_min_addr was bug free (over the years Spender has found multiple problems with my work) this class of bugs would be just a bit less devastating.

Everyone in the kernel development community needs to think of invalid pointer bugs as a larger security threat then they currently do. The lesson here, keep your systems patched.

SELinux is currently weaker in this area for local users. It is stronger in this area for remote network facing daemons. See http://eparis.livejournal.com/ for all the details. Blanket statements in either direction on SELinux and NULL ptr exploits are wrong.

"And obviously this flaw doesn't affect people that don't use any security modules."

Wow, you couldn't be more wrong. The flaw is in the network tunnelling code. Nothing was wrong with the LSMs, spender was just able to get around SELinux protections (by running his code in a domain that wasn't being confined by SELinux, wow, impressive.) Running his exploit in a confined SELinux domain would have prevented any damages. Any other LSM (SMACK/TOMOYO/AppArmour) doesn't even to try to protect against this class of kernel bugs.

"The kernel's not likely to have a "fixed" re-release for this version"

Again, you couldn't be more ignorant. Greg kh has stable releases. He has stable releases for 2.6.30. Magic. A 'fixed' re-release.

To fix some other incorrect statement in these comments. Linux allowed the mapping of page 0. It always has, mainly for msdos compatability. WINE makes use of mapping the zero page, as does the vm86 emulation used by DOSEMU, and a number of programmers have made use of mapping the NULL page as expected behaviour in their programs. I call it bad style, but it works.

When I wrote the Linux kernel patches to prevent the mapping of the NULL page and we specifically wrote it to allow certain programs to do this. As we find and fix those programs we are tightening the restrictions. See how in the 2.6.31 code (long before the exploit was known) we moved the mmap NULL page protections out of the LSM and into the generic security subsystem, thus they could help people who build without any LSM.

The linux kernel (in response to this exploit) has decided to start building with -fno-delete-null-pointer-checks. There is a performance trade off, but it does harden the kernel again future bugs like this one. Normally this would have been a NULL pointer OOPS (and that's how the vulnerability was found and fixed before spender wrote his exploit) when it should have been a fine situation with a safe return code. (I think the argument that the gcc optimization is generally a bug have been sufficiently debunked, it's busted tunneling code, no ifs ands or buts)

I'm working with the gcc team to come up with a way to find these situations but as many have pointed out, considering inline functions and macros it's not uncommon to know that a given branch is impossible to take. Maybe we can use this work to make it faster to find these bugs in the future, but generally, optimizing out branches that are known to be impossible to take is the right thing to do.....

Yes you are missing something. :) The superblock on all extX say what features they support. So when you mount ext3 as ext4 the mount code can look what features that FS supports and use what new features it has available that won't break it as ext3. If you mount and ext3 fs as ext4 you'll get all of the benefits of ext4 like the enhanced inode allocator and what not, but you won't get extents so your huge file support is limited just like ext3) An ext4 fs can NOT be mounted as ext3 as the files will be stored using new features (like extents) which ext3 doesn't understand. Make sense? There will be (or is?) a conversion tool which will be able to downgrade ext4, but you can't just mount backwards.

It's already a technology preview in RHEL 5.3.

I'm glad to see Red Hat and Fedora taking the hard steps to push our technology forward. Precious few organizations employ people to work on things like this, instead expecting others to do the hard work to create and integrate disruptive core technologys. I know Red Hat employs people to work full time on ext4 and they have a person working full time on btrfs (which by all early accounts is supposed to be revolutionary and kick the crap out of everything else out there [even the fabled ZFS] (it pains me to say thanks to oracle for btrfs, but one of their employees is the primary driver) Someone has to do the hard work of being a leader, putting in engineering time, and fixing the bugs before the fanboys can consume (and all too often get credit for) new technology. Thank you Fedora for both the freedom and the constant drive to be on the leading edge of technology.

Obviously I am not a lawyer but the way I read it many people other than Red Hat are protected, but not quite all. If you develop your own project completely from scratch and you are violating this patent (which may or may not be dubious, RH never admitted to violating it or that it was legit) you are on your own. The licence of your wholely new and unrelated project is irrelevant. If you go and get your project accepted into Fedora (pretty easy task) you are then covered since Fedora is a RH brand. Now your upstream code from the Fedora project (and any predecessor code created before you got accepted into Fedora) is now covered by this licence so other distros or projects can take your work use, modify, and distribute it just like any GPL code and are legal. It seems from my reading of all the press over the last 2 days and the RH FAQs like the only condition that needs to be met is that code which makes use of this 'patent' exist in a Red Hat brand. If it exists, existed, or will exist, in Fedora everybody is covered. This is a great thing for RH to do to support all of us who use a RH supported distro or some other distro.