This is joke, right? Or do you really misunderstood the simple issue? [LWN.net]

This is joke, right? Or do you really misunderstood the simple issue?

Posted Mar 8, 2008 17:02 UTC (Sat) by khim (subscriber, #9252)
In reply to: GCC 4.3.0 exposes a kernel bug by roblucid
Parent article: GCC 4.3.0 exposes a kernel bug

If you allow anyone to inject code in your executables you are hosed already. And if don't - you can not exploit this bug. Prerequisites are harsh: gcc 4.3-compiled priveleged daemon and kernel below 2.6.25 ...

Perhaps kernels compiled with gcc < 4.3

May be it's good idea to read the article? It does not matter if your kernel is compiled with gcc 4.2 or gcc 4.3. The question is about things like login or sshd. They must be compiled with gcc 4.3 - only then you can have a problem.

It's not admin-friendly to rely on older kernel source not being built with the latest gcc.

Yup. But that's one and only solution. Why? Kernel pushes gcc to the limit and so kernels always support finite range of compilers supported. "GCC version between x.y.z and x1.y1.z1" was (and is) the only supported mode. If you plan to use kernel 2.6.24 compiled with gcc 4.3 then you should plan to reinstall the system shortly afterwards. If was never supported, and it will not be supported - to compile the kernel with compiler newer then the kernel is insanity.

Past experience with "apparently unexploitable" flaws, tends to suggest that correcting the code is the only safe option.

Code is already corrected - now the question is about deployment...

(Log in to post comments)

This is joke, right? Or do you really misunderstood the simple issue?

Posted Mar 11, 2008 9:45 UTC (Tue) by roblucid (subscriber, #48964) [Link]

No it's not.  Don't think many experienced sysadmins would feel happy 
relying on the "privileged daemon compiled with gcc-4.3" as a sound 
foundation for security.

Securing systems means multiple layers and not leaving apparently small 
flaws and leaving a single point of critical failure.  Then when defense 1 
is broken, the next has to be breached to, which buys time when exploits 
become known, or some script kiddie has started an attack and found a hole 
in some service you offer.

If you're running a web-server for example, you don't give a shell out, 
yet your defense only has to fail once, for some web app to permit code to 
be run.  If you run a host with multiple users, with shell access then 
flipping a register which is meant to be cleared, might cause some 
instability and permit an unintentional DoS.

It doesn't matter, that an exploit is not clear, the fact that it is not 
absolutely unexploitable, argues for patching the kernel as has been done.  
That we agreed on.  My post was not complaining against the kernel, nor 
gcc, but argueing the futileness of patching gcc-4.3 to revert to non-ABI 
behaviour.

Your assumption that gcc-4.3 or another compiler cannot be built by a 
user is wrong, so the logic statement "gcc = 4.3 &  kernel < 2.6.25" 
should actually be the simpler "unpatched kernel < 2.6.25".  You may feel, 
that is too pessimistic, but I'm afraid in the real world root does make 
mistakes, so relying on need for root privilege to install the daemon is 
weak security.

If the kernel is compiled, with an older gcc, then it may very well be 
clearing the DF bit, for the kernel accidentally, and I suspect that the 
reason the kernel wasn't clearing it, was because gcc already did it.  
That's creditting the kernel developers for actually testing conformance 
to the ABI.

As for older kernels, getting compiled with unsupported compilers, 
distro's have done that frequently in the past and also hobbyist types, 
may try latest gcc and see if it works.  A subtle issue like this is 
exactly the type of thing that falls between the cracks.  I agree that 
folk shouldn't do it, but in the real world ppl do build "unsupported" 
combinations and as FOSS doesn't come with a legal warranty, your users 
aren't seeing much difference between that and the situation with the 
correct software versions.

You seem to agree that reverting gcc-4.3 and patching the kernel is the 
correct action, and furthermore that "deployment" may be the weak area, so 
why be so condescending?

Please read the article

Posted Mar 11, 2008 13:44 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

You've got all sorts of misapprehensions about this.

Firstly what you seem to be proposing is that somehow this ABI bug would corrupt the OS
kernel. I can assure you that this cannot happen. Linux* couldn't care two hoots about the DF
bit in the flag register of a userspace process which is all that's being tweaked. However the
process itself might care, and is entitled to ABI correct behaviour - and so Linux needed to
be patched to reset this flag bit when calling the signal handler in the userspace process.

Flipping the DF bit is not a privileged operation, it's a normal function of the x86 processor
family. You can add code to your programs to arbitrarily flip DF if you like, and at most
you'll just manage to make it hang or crash.

To have a security problem, what would be needed is to run privileged code which relies on
this ABI feature, and then send it signals until it malfunctions. In most cases on Linux your
privileged code was compiled with GCC < 4.3 and thus does not rely on this ABI feature. Code
from vendors compiled with a patched GCC 4.3.x will also not be affected. Daemons and other
privileged processes very rarely provide a mechanism to receive signals from unprivileged
users. Most of them do very little in their signal handlers and thus won't be relying on this
ABI feature even with GCC 4.3.0. So you need a very extraordinary set of circumstances to
achieve anything more than crashing your own programs.

The code in which this bug was originally noticed deliberately causes large numbers of
SIGSEGVs during normal operation and handles them by AFAICT calling memmove() from an assembly
language routine. Does that sound like any of the programs running with privileges on your
servers? No, didn't think so.

If you're in the habit of running code created by untrusted users then you don't need this ABI
bug to have problems, indeed it makes no difference at all - you've got a gaping hole in your
security strategy from the start.

* Read NetBSD, FreeBSD, OpenBSD etc. for Linux as you prefer. They all seem to have an
identical bug here, shielded by GCC

Please read the article

Posted Mar 13, 2008 9:00 UTC (Thu) by roblucid (subscriber, #48964) [Link]

No I do get that when programs have been compiled with gcc < 4.3 they 
clear the bit.  It's just that applications suffering obscure memory 
corruption when memory operations go wrong, and a leaking of the bit 
between processes on signals, is not something anyone ought to want on a 
system.

My point was, that contrary to the comments made early on, reverting GCC 
behaviour is not a sane option.  Patching the kernel is.

Please read the article

Posted Mar 13, 2008 9:48 UTC (Thu) by khim (subscriber, #9252) [Link]

It's just that applications suffering obscure memory corruption when memory operations go wrong

Don't use gcc 4.3 to compile your programs then. Or patch your kernel. Your choice.

and a leaking of the bit between processes on signals, is not something anyone ought to want on a system.

You can only leak bit from program to the same program. And if your program does not trust itself - you are hosed anyway.

Once more from the top.
1. Linux, FreeBSD and other kernels provided kind of "changed ABI" - "DF is not guaranteed to be cleared or set when you enter function" was the change from official ABI.
2. GCC before 4.3 produced code which worked correctly with this "changed ABI".
3. GCC 4.3 started to rely on obscure part of ABI and this led to crashes (in some obscure programs but that's not the point).
4. Kernel 2.6.25 fixed problem and now it's safe to use GCC 4.3.
But it does not mean anything for GCC 4.2 and kernel 2.6.24! They have used incorrect ABI all along - but they used it correctly and consistently. Yes, from formal POV kernel is wrong and GCC is right, but in reality you can fix either GCC or kernel - it does not matter which: GCC 4.2 + kernel 2.6.24 is 100% secure and internally consistent combination, GCC 4.3 + kernel 2.6.25 is 100% secure and internally consistent combination (as far as this bug is concerned, of course). End of story.