A feature called System Management Mode included in modern x86 cpus opens the way to the land of kernel space and the quest for ring zero. Federico Biancuzzi interviews French researcher Loïc Duflot to learn about the System Management Mode attack, how to mitigate it, what hardware is vulnerable, and why we should be concerned with recent X Server bugs.
Now, this is the type of article that I enjoy seeing on OSNews! It is informative, intelligent and easy to read for those of us who happen to not be developers or have a PhD in computer science.
Nice to see gems like this, even among the less popular (and, IMO, bad) posts. But I guess not everyone can be pleased by all of the content all of the time.
Apparently Windows is the only OS that is NOT vulnerable, so you won’t see much of a discussion either.
http://www.cansecwest.com/slides06/csw06-duflot.ppt
Slide #41
So what’s up with the oh-so-secure OpenBSD, huh Theo? Installing rootkit in 10 lines of code, LOL.
Edited 2006-05-11 18:00
Blah…
All operating systems running on x86 suffer from hardware vulnerabilities on the x86-platform. It takes a moron to believe otherwise.
Windows does not suffer from this particular X Server bug because Windows does not use the X Server. It has a similar solution, but it isn’t the X Server.
However, one cannot conclude on that background that Windows isn’t vulnerable to hardware bugs.
[EDIT:] But yes to the first poster. It’s nice to see article submissions like this one. More of those, please
Edited 2006-05-11 18:11
All operating systems running on x86 suffer from hardware vulnerabilities on the x86-platform. It takes a moron to believe otherwise.
No, it takes a moron to think this is x86 bug, when in fact it is an OS-level design flaw.
Windows does not suffer from this particular X Server bug because Windows does not use the X Server.
Windows does not suffer from this particular design flaw because it denies any user-mode (ring3) PIO access via EFLAGS.IOPL field. X Server is just an example – it could be any other app.
However, one cannot conclude on that background that Windows isn’t vulnerable to hardware bugs.
I never claimed it wasn’t. This is not a hardware bug.
Edited 2006-05-11 18:27
It’s not the slightest bit related to OS’es.
It’s a weakness in the x86, which manifests itself with certain applications, like the X Server.
Running the X Server in CygWin on Windows is likely to be suffering from this particular vulnerability, as well.
The software bug is merely due to flaws in the hardware design, and in no circumstances related to the OS of choice.
It does not look like you actually read the article.
You need to read the article again.
If OS doesn’t allow PIO access to user mode code, this exploit is not possible.
However, the article doesn’t clearly say if you can carry out this exploit without root privilege or not. If this requires root privilege, then to me it is not a bug. Once you are root, you can exploit the system in whatever way you want. You can easily install a driver to get to kernel mode and do whatever the hell you want.
If on the other hand, a non-root process can do this, then it is definitely a serious bug in *nixes.
dylansmrjones: This exploit is not possible on Windows if you run X as a non-admin. Because a non-admin user mode process can never get PIO access and it can never install a driver to get in kernel mode to get PIO access.
BTW this is *NOT* completely a hardware bug. It is the OS which is giving permissions to sensitive areas first.
Cygwin would not be vulnerable, as windows restricts access to PIO for userspace, it’s that simple, cygwin can’t get around that restriction
It’s not an X Server bug, it’s an exploit that takes advantage of an “unprotected” x86 CPU mode. Due to NT not allowing ring 3 code to access PIO privileges, there is no way to modify the SMI handler — that the researcher currently knows about.
So in reality, no, not all operating systems on x86 suffer from hardware vulnerabilities on the x86-platform. If the OS doesn’t provide the facilities to make the attack possible, that’s the same as saying that that OS is “safe”.
Disclaimer: Didn’t read the article, read the original paper regarding this flaw when it first came to light.
The bug is that it’s possible for the X server to obtain ring 0 privileges (i.e. kernel level privilege to do anything) by abuse of SMM.
HOWEVER
On many platforms (Linux for instance), X11 tends to be given privileges that approximately amount to the same thing. For instance, on x86 Linux a root process can get direct access to IO ports, disable interrupts, map any memory, etc. This effectively means it can always get ring0 privs if it want. The fact that there’s now *another* way for X to do this doesn’t seem like a big issue to me.
It is an issue on OpenBSD because it enables a subverted X server to circumvent the BSD secure levels. They can and do run X11 as non-root without direct access to the IO ports, yet it is still able to obtain ring0 access. Oh dear.
This behaviour is due to a quirk in the way x86 platform chipsets work, and the interaction of this with the way X11 servers are normally run on *nix systems. The problem could be avoided by a better X server architecture (which is the proposed fix from the OBSD folks) which didn’t allow the X server such freedom to drive the hardware as it chose.
The problem is endemic to all designs that allow userspace to do direct HW access. HW is usually not designed for security. The solution is to avoid PIO the way DRI does.
Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; PalmSource/Palm-D050; Blazer/4.3) 16;320×448
“No, it takes a moron to think this is x86 bug, when in fact it is an OS-level design flaw. ”
No, it’s an X.org/XFree design flaw and it affects all OS’s running X.org/XFree.
“It’s a weakness in the x86, which manifests itself with certain applications, like the X Server. ”
No, it’s a weakenss in the X(.org/Free) design in that it *requires* direct hardware access and if your OS wants to run X you’ll have to allow it that access.
If it instead of doing its own hardware access all over the place talked to a, for example, kernel driver doing the access this wouldnt be a problem.
Indeed the article failed to mension GGI and the XGGI server running with “simple-user” privs:
http://marc.theaimsgroup.com/?l=ggi-develop&m=113986229415113
You might want to remove the “Security Bug in x86 Chips” part of the title since that is not what it is. To quote Loic:
“The “beauty” of the attack scheme is that it does not exploit any software or hardware bug. Each step of the attack can be considered legal in the operating system security policy.”
This isn’t an X Server problem. This is shoddy SMM code. SMM is a de facto x86 hypervisor, and this researcher discovered that many SMM implementations have a gaping security hole – it’s the equivalent of an OS letting a user process modify the kernel’s interrupt table. Don’t blame the X Server.
Apparently having a dedicated 16-bit 286-era processor on the motherboard/chipset to handle this code is too complex, so instead SMM has to hijack a complicated processor and in the process open a security hole. Yippee!
> Apparently having a dedicated 16-bit 286-era processor
> on the motherboard/chipset to handle this code is too
> complex, so instead SMM has to hijack a complicated
> processor and in the process open a security hole.
> Yippee!
286 would probably be far overrated. Even some microcontroller would be enough. However, it seems in a way sensible to use the CPU for this to save hardware resource. But then, this is *exactly* the kind of task operating systems are invented for. So instead of adding some strange preemptive 16-bit mode with even more strange memory mapping, why not write a @#$% driver to do these things?
(Possible answer: Because that driver would have to be installed in the base installation of the OS from the beginning, i.e. major OSes would have to include it in their base distribution. The joys of having OSes that try to run the same unmodified executable on all platforms…)
AFAIK SMM was invented by Intel for the purpose of power management (see the APM specification) and system management (correcting RAM ECC errors in software, etc). It was introduced with the 80486, and SMM is not entirely 16 bit – it uses real mode segment addressing with 4 GB segment limits (similar to “unreal mode”).
This isn’t an X Server problem. This is shoddy SMM code. SMM is a de facto x86 hypervisor, and this researcher discovered that many SMM implementations have a gaping security hole – it’s the equivalent of an OS letting a user process modify the kernel’s interrupt table. Don’t blame the X Server.
I agree – I’d call this specific problem a “BIOS chipset initialization security hole” (if the BIOS fails to set the “D_LCK” bit, or worse, requires the “D_LCK” bit to be clear).
Unfortunately nothing is that simple. There’s actually plenty of other things in the chipset (and PCI configuration space) that can be messed with if you’ve got access to all I/O ports – bringing the entire system to a grinding halt wouldn’t be hard. For example, you could enable a chipset’s “ISA hole” from 15 MB to 16 MB to cause 1 MB of physical RAM to suddenly disappear, use the ISA DMA controllers and floppy controller to trash RAM (or copy RAM to a floppy), relocate the video card’s display memory elsewhere so that nothing written to display memory can be seen, use an otherwise idle network card to transfer physical RAM to someone on the internet, wipe hard drives, etc.
I also disagree with the Loïc Duflot’s conclusions. The problem isn’t that user level code (like the X server) is given access to I/O ports, it’s that the OS gives it access to all I/O ports (rather than limiting it’s access to the I/O ports it needs).
It’s the same problem for any code running at CPL=0 because they also have access to all I/O ports. Any device driver running at CPL=0 could potentially have flaws that allow this sort of attack, and something like a “trojan” NVidea driver could theoretically be used to compromise both Windows and Linux.
One solution would be to limit access to I/O ports to what each piece of code needs. For example, only allow the video driver to access I/O ports associated with the video card, only allow a disk driver to access I/O ports associated with the disk controller, only allow a serial port driver to access I/O ports associated with the serial ports, etc.
This would solve all “I/O port access vulnerabilities”, and is fairly common practice for micro-kernels. Most monolithic kernel developers would consider it “bad for performance” though… 🙂
“Don’t blame the X Server.”
Yeah, clearly we shouldnt blame a userland process for requiring direct hardware access and we sure shouldnt listen to Loic when he says it’s not a hardware bug.
“This way, the SMRAM address range is in conflict with the legacy video RAM range. So what happens is that if the CPU is running in protected mode, all accesses to the SMRAM range are forwarded by the chipset to the display adapter.”
Hardware for allowing legacy conflicts, software for not using the resource the secure way. There is nothing the OS could do to prevent this. Its the X server guys who have to watch out for bugs.
But hey they say you need exact chipset->bios combination so for me this exploit is more theoretical and it is wrong to assume that it affects all PC in the world.
Good reading though.