Linux 2.6.30 exploit posted

I could argue that supporting program written for broken systems is not a sane purpose ;)

actually, I believe that the fix for this will be in 2.6.30.2, which is due to be released any time now (potentially over the weekend). the preliminary patches were released on thursday or friday, moments before Greg K-H left on a trip, with the expectation being that if no problems were found with them the -stable release would happen in a couple of days.

I think that if you standardize too much this kind of work, you're gonna strip most of the fun that people who search bugs feel doing it. I don't see any problem if they exaggerate, or if they're narcisists or childish. It's actually funnier if it's like this. And after all, by your reasoning, how would you classify some of Torvalds' incinerating posts? I find them funnier and more entertaining to read than their hypothetical thechnically equivalent but more formal replacement.

If you can't laugh at yourself, others will do it for you.

A static checker could have found the bug. What makes you think a blackhat can't find bugs when they're introduced? They want to actually compromise machines that have unfixed vulnerabilities, you know. And they don't post their findings online, especially in such a nice presentation as mine.

The fact that in my free time I was able to spend 5 minutes and figure out the particular bugfix that was ignored for its security implications was in fact exploitable isn't really relevant here. I'm not the person you need to worry about (unless all you really do worry about is embarrassing public disclosure of embarrassing vulnerabilities like the SELinux one).

BTW, as that hugely embarrassing SELinux vulnerability is currently being brushed under the carpet as an "errata" I've gone ahead and submitted a CVE request for it myself. The previous do_brk() bypass of mmap_min_addr received a CVE in 2007, this case should be no different. An advisory will follow.

While I'm here, just a side-note on why I won't ever be cooperating in ways you might prefer in the future:

On June 2nd, I sent a mail in private to Jakub Jelink, discussing some problems with FORTIFY_SOURCE I encountered when evaluating its usefulness for the kernel (by doing the actual porting work, marking allocators with the appropriate attributes, and implementing a few other tricks of my own) and found it to be very poor, only 40% coverage in the kernel, basically missing everything but the most trivial of cases that didn't need protection in the first place. Specifically one of the things I mentioned was that FORTIFY_SOURCE wasn't able to determine the size of arrays within structures, and given how widely structures are used in the kernel, having proper bounds checking on their elements is pretty important (quoted from his reply):
> I have a structure in grsecurity, struct gr_arg. It looks like:
>
> +struct gr_arg {
> + struct user_acl_role_db role_db;
> + unsigned char pw[GR_PW_LEN];
> + unsigned char salt[GR_SALT_LEN];
> + unsigned char sum[GR_SHA_LEN];
> + unsigned char sp_role[GR_SPROLE_LEN];
> + struct sprole_pw *sprole_pws;
> + dev_t segv_device;
> + ino_t segv_inode;
> + uid_t segv_uid;
> + __u16 num_sprole_pws;
> + __u16 mode;
> +};
>
> I have a function, called chkpw, its declaration looks like:
> int chkpw(struct gr_arg *entry, unsigned char *salt, unsigned char *sum);
>
> within that function, I do the following:
>
> memset(entry->pw, 0, GR_PW_LEN);
>
> If I put a __builtin_object_size(entry->pw, 0/1) check above that, it's
> always -1.

Here's his reply from Jun 3rd:

"The above description is useless, you need to provide complete (though
preferrably minimal) self-contained preprocessed testcase.
I'm not going to second guess what your code looks like."

Apparently my description was so useless that the next day, on Jun 4th, what gets submitted to gcc?
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00419.html

No credit, no reply of thanks. This combined with the attempted cover-up of the SELinux vulnerability means I'll be going back to selling vulnerabilities in any Red Hat-related technologies (exec-shield, SELinux, etc) as I used to in the past. $1000 for an exec-shield vulnerability from back in 2003 I think? (I can't seem to find the picture I took of the check with "exec-shield" in the memo line ;)) which is still not fully fixed today. Maybe it was from 2004, judging by this post where I mention doing so: http://lwn.net/Articles/112880/ It was to a legitimate purchaser, who (unfortunately for you I guess) doesn't have a policy of notifying the vendor.

PS: I don't need a lecture on ego or feeling like I can do things better than everyone else, from the very faszkalap kernel hacker who is hated among everyone for those very things.

-Brad

Hey... I have rarely read such an interesting comment, especially in association with a real security failure.

First, thanks for the nice wrap up.
Second, as I am involved in security-related teaching activities, would you eventually allow me to present your text to my students for commenting?

Finally, let me express some additional concerns.
Governement-funded or organized vulnerability research may actually already be occuring but not leading to security improvements: think of military-funded organizations or simple selfish (and commercially-compatible) self-protection of big players. I wonder how we could guarantee that such organizations do contribute to overall security. But I totally agree with you that such organized research is still too rare; hence we still rely a lot too much on individual achievements in this area.
Then, there is a deeper question: don't we feel the need for technical vulnerability research because we do not put enough efforts on providing security guarantees (or mechanisms, or properties) in our systems? (And yes, I know I speak to an audience who already certainly does much more than any other one in this area - I would probably not even openly express this concern if I did not know that.)

Ah, so fact-based, the parent. Examples?

Gcc isn't assuming the program will crash with (this) undefined behaviour. Gcc is assuming that the program doesn't get into undefined behaviour. And if it does, that is a bug in the program.

The correct behaviour is…, well, undefined. So opening a security hole is no less correct (by definition) than crashing or causing "demons to fly out of your nose".

That is what you say.

When GCC makes that the default behavior, there will be others bashing GCC for not optimizing away an obvious unnecessary null-pointer check.

Whatever GCC does, there will always be folks around here and everywhere else who disagree with it. GCC bashing is just the favorite hobby of the entire FOSS developer community, it seems. Just sad...

That doesn't quite make sense. First, compilers are able to do whatever they like when a program does something undefined -- so in that sense they certainly rely on the ability to make the program do whatever they like when the behavior is undefined (otherwise the behavior would be specified in the standard and it would no longer be undefined). But where the logic in your statement fails is that it is presumably the program which has a need to stick to defined behavior, to well, act in a useful and predictable manner. Any program relying on some specific thing to happen or not happen when it triggers undefined behavior is going to be unhappy with the results. Even if the code is tested and the programmer can see that the compiler does "the right thing", there is no guarantee it will happen that way every time, or that other compilers (or updates to the same compiler) will produce the same effect.

So your other question is who defines what is defined. The C standard defines what things trigger undefined behavior and it is the obligation of the program to avoid them. It's like a contract between programs and the compiler. In a few places specific compilers may define behavior in some of those cases as extensions, but there is no such extension here. Any program which fails to avoid dereferencing of NULL pointers and cares about the subsequent execution of the program is buggy, and blaming the compiler for the problem is not reasonable.

It's normal, and could make sense, to succeed in dereferencing a pointer containing zero if you have readable memory mapped at address zero. Some older platforms used 'page zero' memory as cache -- it was faster (or took less object code) to reach.

So the C standard can say nothing about it. Where the C standard does mention null pointers is in saying that, when assigning (or comparing) the constant zero to a pointer, a specific value must be used that means 'null'. The semantics of this 'null' value need not be the same as the address zero (ie. it may be some special nonzero bit pattern when represented in a particular pointer of a particular type) and this allows for weird platforms where zero is a commonly used address value and there is some other special invalid address register value which can be efficiently detected or used to raise an exception.

OTOH Linux could say something about it, eg. by not permitting anyone to map anything at address zero. This might break one or two native-code emulators of ancient zero-page-using OSes but surely no-one will cry over those in 2009.

None of which is relevant to whether it's legal for gcc to remove code during optimisation that relies on common-but-not-universal behaviour. This is definitely a compiler bug.

It's possible in practice for the pointer to be zero, and for execution to continue after reading the contents of address zero, so the test should never have been removed.

"C" says that once you dereference a null pointer, all bets are off. UNIX says that you get a SIG_SEGV signal that can't be restarted. So, the GCC optimization is for usermode code only.

Anyway, the "it appears to be a GCC bug in the end." bit in the LWN story about this is unjustified IMHO.

I think there are three completely orthogonal issues here, which seems to be confusing people:

1. The kernel is (mostly) written in C and uses a general purpose C compiler (even more than one, if you count Intel). So the kernel should follow the C rules (and the C standard), even if on the surface it seems that these rules don't always make sense in the kernel context. For example, under DOS dereferencing a NULL pointer would not generate any kind of error. That doesn't mean that it is a good practice to remove NULL pointer checks for all reads. It is still undefined behavior according to the C standard and any C compiler for DOS is free to apply the same (correct!) optimization.

I think what people don't realize is that such optimizations are not only valid, but necessary. While there are the few exceptional cases like this one where they seem to get in the way, they are useful in the majority of cases.

2. Whether the _tun_ pointer should ever be expected to be NULL in this point. I have no idea, but if it is supposed to have been checked earlier, it is reasonable not to check again and this is a simple logical bug.

3. Whether the kernel should trap NULL pointer accesses in hardware for kernel code. Again I don't know, but personally I prefer that it did, unless there is good reason not to. Is there one?

Still relying on this can be risky, for example:
int * a = NULL;
x = a[10000];

The first page may be unmapped, but we are not accessing it.

You have a nice memory: I remember being advised to strip a BUG_ON line since the kernel OOPS mechanism will handle it - http://lkml.org/lkml/2008/2/13/71

I'm not sure if (or how) can this be exploited though ...

Question for language lawyers:

If the behaviour of a program is undefined, we can't rule out the risk that it is exploitable.

So how might we move towards eliminating undefined behaviour from a given piece of software?

It would be nice if the compiler was able to produce meaningful warnings everywhere that the program might ever do anything undefined.

Of course this is impossible in the general case because the task of static analysis is NP-complete (mostly because the program's inputs are not known to the compiler).

However there is surely a way to produce *many* such meaningful warnings. In particular, it must be possible wherever the compiler is presently able to exploit the undefined-ness of an operation to make an optimisation.

Of course if we were to attempt this immediately we would start with a huge, huge number of false positives due to race conditions and the like which are for the most part not bothersome in practice.

If it were then possible to gradually reduce these warnings by meaningful annotations and the judicious introduction of memory barriers and relevant runtime checking, any progress would then be most reassuring.

Your post is the perfect reason why I'm the security expert and you're not.

Your entire "suppose I find a way" argument is based off a non-existent bug. I was talking about the vulnerability I exploited. The only way you're going to turn that into a security problem for this firewall app you've invented is if you can get arbitrary code execution in the firewall app to force it to open a device it never wanted to open in the first place, and then perform an additional poll on the device that it never wanted to do in the first place. If you have arbitrary code execution within the firewall app, you might as well just call kill (or just fail with your arbitrary code execution and crash the process)!

Try again.

-Brad

Well, since he just said elsewhere in this thread that's he's going to start selling RH vulnerabilities, one must assume the answer, this time, was no, but in future will be yes.