Linux 2.6.30 exploit posted

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.)