| |||||||||||||
Please read the articlePlease read the articlePosted Mar 11, 2008 13:44 UTC (Tue) by tialaramex (subscriber, #21167)In reply to: This is joke, right? Or do you really misunderstood the simple issue? by roblucid Parent article: GCC 4.3.0 exposes a kernel bug
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
(Log in to post comments)
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.
|
|||||||||||||