Re: security bug in x86 hardware (thanks to X WIndows)
On Tue, May 16, 2006 at 03:26:39PM +1000, Steffen Kluge wrote: On Sat, 2006-05-13 at 16:18 +0200, Ed White wrote: It seems XFree people disagree... [...] ...and some Linux developers too... Alan Cox: What it essentially says is if you can hack the machine enough to get the ability to issue raw i/o accesses you can get any other power you want. Thats always been true. Using SMM to do this seems awfully hard work. He said that in reply to you saying: The big problem is that the attack is possible thanks to the way X Windows is designed He didn't comment on whether X is flawed or not, but rather that from a Linux perspective this whole issue is a storm in a tea cup. In (distribution default) Linux it is always possible for root to get ring 0 access. Simply because root can load kernel modules. That's what root kits do. Fumbling registers through a hacked X server is a novel but rather complicated way, in comparison. Hence, securing a Linux server has always meant (besides removing X and tons of other crud) to build a kernel that doesn't support loadable modules. And adding something to ensure that /dev/*mem cannot be written by root. There exist pre-written rootkits which load directly via /dev/mem, IIRC. Of course, simply disabling loadable modules does do some good... Joachim
Re: security bug in x86 hardware (thanks to X WIndows)
On Tue, May 16, 2006 at 11:27:00AM +0200, Joachim Schipper wrote: On Tue, May 16, 2006 at 03:26:39PM +1000, Steffen Kluge wrote: On Sat, 2006-05-13 at 16:18 +0200, Ed White wrote: It seems XFree people disagree... [...] ...and some Linux developers too... Alan Cox: What it essentially says is if you can hack the machine enough to get the ability to issue raw i/o accesses you can get any other power you want. Thats always been true. Using SMM to do this seems awfully hard work. He said that in reply to you saying: The big problem is that the attack is possible thanks to the way X Windows is designed He didn't comment on whether X is flawed or not, but rather that from a Linux perspective this whole issue is a storm in a tea cup. In (distribution default) Linux it is always possible for root to get ring 0 access. Simply because root can load kernel modules. That's what root kits do. Fumbling registers through a hacked X server is a novel but rather complicated way, in comparison. Hence, securing a Linux server has always meant (besides removing X and tons of other crud) to build a kernel that doesn't support loadable modules. And adding something to ensure that /dev/*mem cannot be written by root. There exist pre-written rootkits which load directly via /dev/mem, IIRC. Of course, simply disabling loadable modules does do some good... and this is related to openbsd how? cu -- paranoic mickey (my employers have changed but, the name has remained)
Re: security bug in x86 hardware (thanks to X WIndows)
Hi! On Sat, May 13, 2006 at 02:07:35PM -0600, Theo de Raadt wrote: [...] If you want X to talk to IO devices, what next? ls? Oh why not? Surely, you'd get the directory listings 0.0005 percent faster that way, won't ya? ;-) SCNR, tongue in cheek, of course. Kind regards, Hannah.
Re: security bug in x86 hardware (thanks to X WIndows)
On Sat, 2006-05-13 at 16:18 +0200, Ed White wrote: It seems XFree people disagree... [...] ...and some Linux developers too... Alan Cox: What it essentially says is if you can hack the machine enough to get the ability to issue raw i/o accesses you can get any other power you want. Thats always been true. Using SMM to do this seems awfully hard work. He said that in reply to you saying: The big problem is that the attack is possible thanks to the way X Windows is designed He didn't comment on whether X is flawed or not, but rather that from a Linux perspective this whole issue is a storm in a tea cup. In (distribution default) Linux it is always possible for root to get ring 0 access. Simply because root can load kernel modules. That's what root kits do. Fumbling registers through a hacked X server is a novel but rather complicated way, in comparison. Hence, securing a Linux server has always meant (besides removing X and tons of other crud) to build a kernel that doesn't support loadable modules. Cheers Steffen.
Re: security bug in x86 hardware (thanks to X WIndows)
It seems XFree people disagree... Marc Aurele La France: Contrary to what too many security pundits think, limiting root's power doesn't solve anything. Like bugs, security issues will forever be uncovered, whether they be in setuid applications like an X server or in a kernel itself. The trick, it seems, is to understand where to properly fix them, instead of sowing workarounds all over the place... ( http://marc.theaimsgroup.com/?t=11473584346r=1w=2 ) ...and some Linux developers too... Alan Cox: What it essentially says is if you can hack the machine enough to get the ability to issue raw i/o accesses you can get any other power you want. Thats always been true. Using SMM to do this seems awfully hard work. ( http://marc.theaimsgroup.com/?t=11473584324r=1w=2 )
Re: security bug in x86 hardware (thanks to X WIndows)
Marc Aurele La France: Contrary to what too many security pundits think, limiting root's power doesn't solve anything. Like bugs, security issues will forever be uncovered, whether they be in setuid applications like an X server or in a kernel itself. The trick, it seems, is to understand where to properly fix them, instead of sowing workarounds all over the place... ( http://marc.theaimsgroup.com/?t=11473584346r=1w=2 ) I think that's been agreed to many times by the OpenBSD developers: you can't effectively limit root's ability to do bad things, and pretending you did is just fooling the good guys and making the bad guys giggle. Wrong. You can limit roots ability to do some bad things. We try to do that. Even root cannot open /dev/*mem for write. We are trying to be protective, but the requirements of X stops us from doing so. This isn't about root. Or at least, it shouldn't be. Except it is, because of how much of the X code is doing root-like things. X is not doing root-like things. X is talking to IO devices. Root does not talk to IO devices. Root only talks to the kernel. If you are going to ran on a topic like this, you HAVE TO KNOW WHAT YOU ARE TALKING ABOUT. Nick, you don't know what you are talking about. But Ed, you interviewed someone in detail about the issue, and you still managed to get it wrong and you still don't understand it. Get a grip, please. In the Unix system view, anything which needs to talk to raw devices INSTEAD OF THE KERNEL DOING SO is broken. There are no apologies to be made. Period. If you want X to talk to IO devices, what next? ls?
security bug in x86 hardware (thanks to X WIndows)
A researcher of the french NSA discovered a scary vulnerability in modern x86 cpus and chipsets that expose the kernel to direct tampering. http://www.securityfocus.com/print/columnists/402 The problem is that a feature called System Management Mode could be used to bypass the kernel and execute code at the highest level possible: ring zero. The big problem is that the attack is possible thanks to the way X Windows is designed, and so the only way to eradicate it is to redesign it, moving video card driver into the kernel, but it seems that this cannot be done also for missing drivers and documentation! This is another example of insecurity that cannot be fixed because of unresponsible vendors...
Re: security bug in x86 hardware (thanks to X WIndows)
On Thu, 11 May 2006 12:00:40 +0200, Ed White [EMAIL PROTECTED] said: A researcher of the french NSA discovered a scary vulnerability in modern x86 cpus and chipsets that expose the kernel to direct tampering. http://www.securityfocus.com/print/columnists/402 The problem is that a feature called System Management Mode could be used to bypass the kernel and execute code at the highest level possible: ring zero. The big problem is that the attack is possible thanks to the way X Windows is designed, and so the only way to eradicate it is to redesign it, moving video card driver into the kernel, but it seems that this cannot be done also for missing drivers and documentation! This is another example of insecurity that cannot be fixed because of unresponsible vendors... This has been disscused; http://marc.theaimsgroup.com/?l=openbsd-miscm=114657401630096w=2 If I understand correctly from what I've been told, this is not a hardware issue but an 'X' issue. -- Eric Furman [EMAIL PROTECTED]
Re: security bug in x86 hardware (thanks to X WIndows)
http://marc.theaimsgroup.com/?l=openbsd-miscm=114657401630096w=2 If I understand correctly from what I've been told, this is not a hardware issue but an 'X' issue. It is the job of the operating system to shield the hardware from userland processes. That's what every operating system does. Some do a better job of this than others. But when an operating system fails to do this shielding, it is almost always a bug in the operating system. However, in this case, we cannot solve this in the operating system. The X developers have created an X server which *REQUIRES* access the raw hardware. Therefore all the operating systems developers have given the X server such access, by creating a hole in their operating system, which permits the X server to access any chip-level registers it wants. This is called the device drivers in userland model. It violates all the security models you will hear of in a university class. Having done so, they place operating system designers in the situation of choosing between the two options: Our users cannot run X or there must be a hole in our operating system. Guess which choice every vendor makes? We provide a sysctl to let the user decide -- that is what the aperture sysctl is for. And we admit that is a cop-out. That's because there is no operating system level solution to the problem. At least we did not cop out as far as other vendors, who let any root process play with the any registers. We only let one root process play with the registers at a time. This is not a strong solution, but it the best we can do. But let me be clear -- the X developers are a bunch of shameless vendor-loving lapdogs who sure are taking their time at solving this 10 year old problem! They spend way more time chasing the latest vendor binary loaded device driver, than they do solving this obvious problem. (Translation: They don't want to change how X works, because it would break the vendor binary drivers from ATI and NVIDIA. That is part of what happens when X developers get jobs at vendors). What Loic found is just one example of perhaps 50 other serious equivelant security problems. Or maybe more. Most modern video chipsets can DMA all over the address space if requested. Many have processors that code could be loaded into, even surviving reboots. If there is a one bug in the X server, your machine is compromised. How does this get solved? If the X server did not require direct hardware access these problem would go away immediately. This requires that a proper abstraction be designed, so that a kernel device driver did the nasty register bits, and then communicated via a sanitized channel to the X server. This is the obvious seperation model that all other Unix things use. Unix processes use read() and write() to modify files. You don't see them talking directly to SATA chipsets do you? If they show up and provide a simple specification for such an abstration layer between a kernel video driver and a X video driver, and helped us a little bit with the registers, the problem would go away almost immediately. That requires them to do some clever design, but it is clear they know more about past, current, and future video chipsets. They know the hardware, and we do not. They can solve this for all X-running operating systems today, or they can cop out and not solve it ever. They've had 10 years, and yet every year they get more entrenched in the entirely insecure model of gigantic process running as root, which accesses registers like mad. This problem is ENTIRELY the X group's fault! They have failed us. Ten years ago they were laughing at Microsoft for moving their video subsystem into their kernel, but now the joke is on the X developers, because what Microsoft did solved all these driver security problems! This is 100% an X server bug. It is not a hardware bug, and it is not an operating system bug. [Feel free to forward this anywhere; I feel that Loic's original announcement totally missed at assigning the blame where it lies, and the result is that it is not being fixed.]
