Recent Features
| |||||||||||||
GCC 4.3.0 exposes a kernel bugGCC 4.3.0 exposes a kernel bugPosted Mar 8, 2008 13:32 UTC (Sat) by roblucid (subscriber, #48964)Parent article: GCC 4.3.0 exposes a kernel bug
Reverting gcc-4.3 doesn't help matters. Now this DF bit flaw is known, then anyone can patch a compiler or use assembler to attempt to craft an exploit in application code. The kernel is broken, it should not rely on called code to clear the flag, but actually ensure the registers are saved, set & restored according to ABI. Perhaps kernels compiled with gcc < 4.3, can rely on gcc clearing the flag when the signal handler is called in a subroutine, in which case it is reasonable to argue that back-porting a fix to support gcc-4.3 may not be absolutely necessary. But it's probably as simple to patch stable kernel updates with the fix, as it is to detect and warn about a build using 4.3. It's not admin-friendly to rely on older kernel source not being built with the latest gcc. Past experience with "apparently unexploitable" flaws, tends to suggest that correcting the code is the only safe option.
(Log in to post comments)
This is joke, right? Or do you really misunderstood the simple issue? Posted Mar 8, 2008 17:02 UTC (Sat) by khim (subscriber, #9252) [Link] 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...
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.
|
|||||||||||||