It does sound rather...

...more like a compiler issue to me from what was said in the article: Optimising-out bounds- and/or null-checking code!!!

Not impressed with the kernel devs' responses anyway.

@LaeMi Qian

That was my first thought too

Couldn't they use the same source code with... you know... a GOOD compiler that actually compiles all of the code?

I can't believe...

That any of this is an issue considering the sheer number of competent coders that are out there. This is the kind of stuff that I expect from M$.

Security First

I want to know who's idea it was to have the compiler remove NULL pointer checks by default. If you are testing for NULL you are doing it for a reason!

The way I see it this is not a failure of the kernel team for not specifying the -fno-delete-null-pointer-checks compiler flag, it is a failure of the gcc team having the compiler do away with such checks by default!

I for one, would prefer a kernel that spends a few extra cycles testing for bad parameters, to getting my system reamed by some pimply script kiddie in china!

gcc flag

Well, this interested me, so I wanted to check. Here is what "info" says about that gcc flag:

-fdelete-null-pointer-checks

Use global dataflow analysis to identify and eliminate useless checks for null pointers. The compiler assumes that dereferencing a null pointer would have halted the program. If a pointer is checked after it has already been dereferenced, it cannot be null.

In some environments, this assumption is not true, and programs can safely dereference null pointers. Use -fno-delete-null-pointer-checks to disable this optimization for programs which depend on that behavior.

Enabled at levels -O2, -O3, -Os.

I don't know the kernel environment, so I don't know what happens on a NULL pointer dereference there. But, with typical user code, what gcc is doing is reasonable, if a bit extreme.

The bug is in the kernel code, where the check is *after* the dereference. Even if the author knows that that works in the kernel environment, I think it is still a bad idea because it is quite non-obvious. If performance is that critical, then add a comment explaining what is going on. Adding the gcc flag to the kernel compile flags will help.

All IMHO of course - I'm not a kernel developer.

Microsoft

Funny, normally if it's a Windows vulnerability you have a trillion Linux heads jumping up and down in the comments forum. When it happens with Linux I notice nobody from the MS camp can be bothered :).

So, no danger whatsoever then?

Let me check, this is a potential *compiling* problem, so the kernel code is sound. The compiler is OK, too. It´s just a matter of passing the right options at compilation time. Hardly a Linux problem then. More like a *potential* vendor problem...

Good to flag, so that self-compiling guys don get caught pants down, but hardly the end of the world. Especially as, from what I gathered, any exploit would need to run with the setuid bit set, which, let´s be honest, is not bloody likely to happen in any standard distribution, let alone hardened ones. Dubious setuid programs are likely to be prevented from running in the first place. It looks suspiciously like a ¨Oh my dog, if I run exploit code as root my system might be vulnerable!¨. Wake up people, regardless of the OS if you run exploit code as root you´re screwed. And any attack that needs admin privilege to be efficient is a non-attack to begin with. If I get admin access to your system, I am totally not going to try and exploit an obscure vuln in the kernel. There are much easier and more interesting things to be done. I side with Linus on this one. Any program running with the setuid bit set *is* a potential hazard and should be carefully reviewed, that´s why it´s considered bad practice, and that´s why it´s forbidden (or triggers massive warnings) in most serious distros. Now if your sysadmin is willing to make his system wide open, it´s hardly an OS problem, is it?

It´s still a clever attack, one of which might spread using social engineering to root Ubuntu n00bz. Oh, except that Ubuntu doesn´t seem to be vulnerable (yet).

Just one more thing, hardening a system doesn´t mean running SELinux. It means (amongst other things) that only trusted code is allowed to run, so this attack code is never going to be allowed to run in the first place. To this regard, the article is misleading: hardened systems are completely, absolutely, positively, 100% safe.

For one second I thought some of my systems could be vulnerable, I´ll just relax and have a pint or ten now...

@Alex 3

You'll find that most Windows users are quite well-adjusted and not likely to jump on the fanboy bandwagon, like how I see some Linux users/zealots do so (I am not saying that all are like this, just enough to make it noticeable)

I have grown tired of all the fanboism that comes with a story that projects Microsoft / Linux / Mac / etc in a less-than-perfect light. I wonder when the time will come that people realize that it is just a personal choice and no matter what is poster on a forum will never change the minds of others, and that extreme thinking only takes away from your argument.

I suppose this is that same as how everyone has seen the Muslims / Christians / Jews, a few extremists will cast the entire religion in bad light and then everyone else will assume that a person from another religion is a terrorist / bible-thumping racist / money-grubber.

Life has taught me that there will always be trolls harming the adoption of good ideas, people constantly using inflammatory phrases in an attempt to convert people to his or her side but rather harming their own position. Perhaps the only way to treat people like this is just to ignore them, to effectively deny them the attention that they so crave.

ZZzzzzz

It's a code bug, not a compiler bug. The compiler ignores the redundant NULL check after the pointer's been used (which, assuming the compiler is smart enough to work out if a pointer may have changed its reference, is perfectly reasonable). So, surprise surprise, open source doesn't lead to perfect coding however much some people believe it does. True, this isn't a major issue, it's still slightly worrying that NULL reference checks aren't checked with a static analysis tool before releases..I would have thought that was pretty standard practice for something as important as an OS kernel.

Enough rope to hang themselves

So this is why people developed Java, C# and other "less flexible" environments.

Because if you give them enough rope, the programmers will hang themselves.

As they have, again.

Major flaw?

> "Setuid is well-known as a chronic security hole," Rob Graham, CEO of

> Errata Security wrote in an email. "Torvalds is right, it's not a kernel issue,

> but it is a design 'flaw' that is inherited from Unix. There is no easy

> solution to the problem, though, so it's going to be with us for many

> years to come."

Um, so doesn't his translate as "Linux is known to have a major security hole that is unlikely to be fixed in the near future"?

Torvalds is right, really

This 'exploit' requires the user to have root in the first place, to inject a setuid program into the system (which would be caught by the next run of tripwire and SELinux wouldn't let it run anyway, but let's not let facts get in the way of a good story).

If the bad guy gets root = game over. Anything else they do is just icing.. even SELinux isn't an absolute defence against this.

I agree the optimisation flag on gcc is the real bug - it should be flagging these dereferences as errors not deleting the tests.

Oh no

Quick everyone, dump linux and run back to the safety of windows

Actually I what I suspect will happen is an advisory to compile the kernel correctly

But I wonder if windows has the same vulnerbility?

@Alex 3

Its because the M$ Camp (me included) all have hangovers on Saturday morning as we were all out last night with real women in real pubs not geeking out over some compiler issue.

Obligatory flame

*nix sux - cry yourself to sleep cos some bloke with a beard made a mistake in your shitty OS

(I don't care really - just joining in for the sake of it)

Well fix it then!

I have not looked at the code in question and have no intention of doing so, but according to the previous comments, the problem is either a compiler bug (though I see that this is disputed) or the code is checking for a NULL reference AFTER it has dereferenced it, which even if it is legal on a particular platform, is a bloody stupid thing to be doing!!!

Either way, this should be trivial to fix (ok - fixing the compiler could take a while if that really is the issue, but it's hardly insurmountable).

But being Linux, I suppose those responsible need to slag each other off and argue and talk shite for a couple of months before anything actually happens. Mmm.... I think I'll stick with BSD, thanks.

@Francis Vaughan

> "This is sort of worrying really. One would have thought that by now the kernel writers would have spent the time to work with gcc and identify all the optimisations and clearly understand which ones are inconsistent with the peculiar constraints of either secure or kernel mode code."

They do, and the gcc team are happy to work with them and add new options or modify optimisations to make the compiler more suitable for their usage. But I don't know of anywhere the kernel team have ever sat down and made a clear list of what they do and don't want the compiler to do; they're a bit reactive rather than proactive, what tends to happen is that some optimisation turns out to cause a problem for some bit of code in the kernel, the kernel team approaches the gcc team and gets the problem addressed, then six months later it all happens again...

>" Indeed, it might be nice if the gcc developers took a moment out to provide a list of know good optimisations that do not rely on assumptions about memory layout, exception behaviour and likely, but not guarenteed, code structure. Maybe adding a --secure-optimisations-only flag would be a good thing. Depending upon other developers to read the fine print of each and every optimisation flag is clearly not enough. "

Now you wait just a cotton-pickin' minute there. Kernel development is hard-core stuff, and not suitable for amateurs and dabblers. You need to know how a computer works from top to bottom to do it, you need to understand everything from hardware and busses and memory accesses and caching to low level assembly and synchronisation and threading techniques up to the level of security and usage patterns and efficient algorithm design - and you need to understand how the toolchain works and what it does. Kernel developers have very special and unusual requirements, and a compiler is a general purpose tool for a broad audience. It is for kernel devs to know and clearly explain their requirements, not for non-experts (compiler devs) to attempt to second-guess them. They should absolutely be expected to read the fine print of the opimisation flags they want to use to build their code - it's only one more drop in the ocean of fine print they need to read and understand to write reliable kernel code.

Passing the buck

There seems to be confusion here as to whether it was a compiler bug or a coding error, whether the kernel is flawed or not ...

If it is the compiler optimising away something when it shouldn't have, this is a fail for the compiler developers.

If it's a case of the source code being correct and the compiler optimised away a null check this is a fail for the developers who built the kernel and their process, but not a fail for Linux per se.

If the source code is incorrect then that's a fail for the kernel programmers and no amount of buck passing to the compiler or arguments that it's not a bug will wash.

No matter how the bug arose, if it exists, is exploitable and demonstrably so in the field, it's a huge fail for Linux either way, and trying to claim it's not worth worrying over is simply trying to downplay the issue.

If there's no source code error, the compiler did not optimise away something it should not, and no exploitable bug exist then I'll agree it's a storm in a tea-cup. Unfortunately that does not seem to be the case.

The bug is in the kernel, not the compiler.

The compiler is a red herring. It doesn't delete NULL pointer checks - *UNLESS* you've already dereferenced the pointer, in which case it quite reasonably assumes that you've already crashed before you get to the check anyway - and the exploit proves that it is correct in this assumption, or rather that crashing would be a best case! But testing for a NULL pointer at the end of the routine is just too late: the bug occurs here:

struct sock *sk = tun->sk;

At that moment, because it is allowed for a user process to map memory at address zero, what you have done is inject a user-controlled data structure into the kernel, which implicitly trusts its own data structures. That is the security violation, and it's nothing to do with the compiler, it's more a consequence of a false assumption in the kernel:

1) I can trust all pointers to kernel objects, because they will only point into kernel space and only privileged (i.e. trusted) code can place anything in kernel space.

2) But NULL is a pointer value and it is not in kernel space.

3) The kernel trusts *all* pointer values, incuding the one that happens not to be in kernel space but is under user control.

Ouch. The false assumption could be stated in a single sentence as "we can trust all pointer values, including NULL, because even though it's technically not a kernel address it will always make a crash if you access it". But no, it won't, that's just not true.

What might work better would be to build an option in the compiler to use a value like 0xffffffff as a NULL pointer instead of numerical zero. Or for a few pages (maybe even a few meg?) down at the zero end of memory to be declared 'honorary kernel space', protected by the same kind of PTEs that prevent the user accessing kernel space, and not mmap'able, although that might only mitigate rather than fully block the entire class of exploit.

I don't understand grsecspender's response:

>"from a source review, the bug is unexploitable"

We've known for some time that dereferencing a possibly-NULL pointer is exploitable, it was first shown by that ARM exploit by Barnaby Jack

http://www.theregister.co.uk/2007/06/13/null_exploit_interview/

then there was the SWF/ActionScript null pointer dereference by Mark Dowd

http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf

so frankly, any source code audit that doesn't ask the question "Could this pointer possibly be NULL?" is not asking the right questions at all. I think it's fair to say that there are two bugs: the use-before-NULL-check bug is one, and the user-is-allowed-to-mmap-NULL is the underlying and more serious bug which is what enables this and the whole class of other similar bugs to be exploitable. (You could probably argue that a third bug is in the code that calls this routine while passing it a NULL pointer in the first place.)

so what!!

Put this way I know which OS I would use to connect to the internet ! the one I've been running for the last 7 years with no anti-virus,spamware etc.... that will be LINUX then !!!!

The problem is C.

That GCC was optimising-out a null-ref check when it could clearly see that the variable had already been used, is *expected behaviour* for the compiler and clearly documented in its manual. If the programmer couldn't be bothered to RTFM, that's *his* fault. not the compiler developers'.

That non-time-critical code for an allegedly modern operating system is being written in a portable assembly language that's getting on for nearly 40 years old is the real bug here. Even my humble Nokia 2630 is more powerful than the computers C was created for.

Oh yes: for those who haven't read the original article the Register's piece was based on, take note of the following quote from grsecurity's own website:

"Due to Linux kernel developers continuing to silently fix exploitable bugs (in particular, trivially exploitable NULL ptr dereference bugs continue to be fixed without any mention of their security implications) we continue to suggest that the 2.6 kernels be avoided if possible."

Note that they're referring to *multiple* instances of these kinds of bugs. The line people enjoy quoting was just one example, which the researcher used to write his proof of concept exploit. That the Linux kernel is *riddled* with such bugs reflects poorly on its developers.

This is also the kind of bug which, had the software been written using half-decent tools, would never have made it into the released code in the first place. For all the criticisms of Microsoft's ".NET" languages, the simple fact is that C# wouldn't have let you write such bad code in the first place. When a user interface—and that's all programming languages are—makes unwanted actions easy to perform, it is time to replace it.

Microsoft may have their flaws, but at least they're trying to do something about the appalling tools this industry insists on using. They're still a long way from development nirvana, but at least it's *something*.

(Oh yes: my computer is a Macbook Pro, not a Windows box. So please don't waste time accusing me of fanboyism. There's no such thing as a "best" platform. Only a "least worst".)

@The real problem(s)

>"The first, and most critical problem, is a bug in GCC, where it optimizes away null pointer checks in some cases where it should be giving a fatal compile time error."

It's not a bug. It is an explicitly documented feature in the manual, which also warns you to take care with it:

> >" `-fdelete-null-pointer-checks'

> >Assume that programs cannot safely dereference null pointers, and that no code or data element resides there. This enables simple constant folding optimizations at all optimization levels. In addition, other optimization passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these assume that if a pointer is checked after it has already been dereferenced, it cannot be null.

> >Note however that in some environments this assumption is not true. Use `-fno-delete-null-pointer-checks' to disable this optimization for programs which depend on that behavior.

> >Some targets, especially embedded ones, disable this option at all levels. Otherwise it is enabled at all levels: `-O0', `-O1', `-O2', `-O3', `-Os'. Passes that use the information are enabled independently at different optimization levels. "

>"That's right. I'm saying GCC should bomb on this code, complaining that the pointer is used before the null pointer check."

I'm saying that when the user explicitly tells GCC to assume that it can do this, GCC should assume that it can do this, and if it is not true, the user should not have told lies to the compiler, and the compiler should do what the user tells it. Maybe you *want* to get a SEGV if the pointer is NULL because you plan to handle that elsewhere? The compiler can't second guess you. You told it that control flow cannot possibly reach that test if the pointer is NULL; it would be stupid of the compiler to bother inserting it.

>"Note: I think GCC can safely optimize away redundant null pointer checks - and I've certainly seen code that has those. But optimizing away a null pointer check simply because it's already seen broken code is stupid."

It's not stupid. The vast majority of these checks are not going to come from buggy code like this, but from places where any/and/or/all of macro expansion, inlining and templating have combined to generate inefficient code. If the compiler wasn't very aggressive with optimising this stuff, C++ templates would still be the hideous bloated monstrosities they used to be back in the 90s - i.e. practically unusable in anything that has to be the least bit efficient.

You can argue about whether this is a "dangerous optimisation", and should only go in -O3 by default (I might agree with you), or whether it shouldn't be turned on by default at all but always left to the user to request (I'd probably disagree), and you can argue that it should generate a warning (I'd certainly agree with you, but I might consider that sufficient reason to leave it enabled at lower -O levels), but calling it "stupid" is simplistic and lacks insight into the issues. As I think I mentioned once before, GCC is a general purpose tool that must work for a huge range of different applications from small realtime embedded to overnight number crunching batch jobs. No single set of optimisations is ever going to be completely right for all those applications, and the -O levels are crude guidelines, but if you have a very specialised need, you need to take control of how you use your compiler.

Argument is good

Maybe the point is being missed here.

I doubt that anyone regards the existence of an exploitable bug/feature in Linux to be good. However, ask yourselves why there is argument about whose "fault" it is...

In a complex system, one always tries to put the right solution in the right place. There are several ways this problem might be fixed. Choosing the wrong one might fix it more quickly, but may cause problems later. If speed is not the over-riding issue (and it seems it isn't) then thinking carefully (and this means arguing) about whose responsibility it is to protect against this problem is the correct response.

Once you have the correct protection installed in the correct place and everyone knows whose responsibility it is to look after this in future, then you have a more robust system. Failing to argue this out and fixing it the wrong way just starts you on the path towards a system that's unmanageable from a security point of view. I think you all know the example I'm thinking of...

Binary Is Better Then?

So perhaps the notion that even the kernel should be distributed as source code and compiled is not such great idea after all????

And this is why Linux is not popular

When an article of this nature comes up for Mac or Windows, we flame each other, etc, but at the end of the day, the company fixes it. When this comes up for Linux, a whole bunch of code monkeys have a pissing contest ("I know more about coing than you, look at this crap I typed" and "mom, mon, he said I couldn't code, tell his mother so he gets spanked") and argue that its a compiler issue.

And this is why Linux is shite, its for code monkeys, who actually like to spend their weekends coding and compiling, rather than having a life. As they say, you get what you pay for.

TANSTAAFL

I not a few things

1) Big geek fight over who's fault it is - problem not addressed

2) Much finger pointing - problem not addressed

3) "It's a feature!" (of either the kernel or GCC) - problem not addressed

So Linux out in the field has (or will have...) a critical security flaw and the freetards are too busy waving their pocket protectors about to actually fix the problem. With an attitude like that, is it any wonder most organisations who rely on IT to run their business would not touch Linux with a shitty stick?

Get your act together you bunch of jumped-up primadonnas; you are not doing yourselves, Linux or the open source community any favours with your public bitch-fest.

Clarity.

So just to be clear, the problem is:

Bad code?

Bad compiler flags?

Bad Compiler?

Uncaring developers?

Arrogant developers?

The C language itself?

Security researchers for bringing up the bug?

A lack of using proper tools to analyse the code?

Hundreds of eyes, hundreds of opinions, hundreds of wrong ideas. Wisdom of the crowd innit?