The quest for ring zero

'One ring to rule them all...'

Is Windows vulnerable too?

Windows NT, XP, Vista are not vulnerable to this attack scheme since there seems to be no way for ring 3 code to request PIO access privileges.

But, as I said before, if there exists other means to modify SMI handler, then this functionality can be disastrous because execution in SMM is transparent from the operating system point of view.

So we need to find the right mix of vulnerable hardware AND software?

The real trouble with such a scheme is that some hardware are potentially vulnerable, other are not. When the hardware is potentially vulnerable, there are several possibilities:

  • The system may not be vulnerable (No PIO accesses).
  • The superuser is allowed PIO accesses but there is no restriction of superuser privileges on the system, so the attack scheme is pointless here (Linux).
  • The system is vulnerable under some (highly improbable) configuration.
  • The list of such configurations can be very long. Bad configurations of GRSecurity under Linux could be vulnerable.
  • Some security mechanism (chroot, securelevel, capabilities, virtualisation...) may be circumvented using the attack scheme. Checking each of them on different hardware platforms will be a very difficult task.

All I can tell for the time being is that some configuration are vulnerable, and others are not.

How can we find out if our hardware is vulnerable?

Any x86 processor (whatever the manufacturer is) is theoretically vulnerable as long as it is used along with a chipset encompassing a "SMRAM control register". The few desktops I had the opportunity to test did actually encompass this functionality.

There does not seem to exist any tool to check. The best way is to check in the chipset's documentation or try to read the PIO address usually corresponding to the SMRAM control register.

In the paper [PDF] I saw a schema with an AGP bus for the video card. Is the video memory range still the same if the motherboard has just a PCI Express slot and card?

Yes, the legacy video RAM range is exactly the same for compatibility reasons.

Are other architectures (Sparc, PowerPC, ...) vulnerable?

To be able to carry out the privilege escalation scheme, the attacker needs to be able to write to Programmed I/O ports from userspace. As far as I know this is not possible on architectures other than x86.

I saw this email from Theo de Raadt that talks about other architectures too...

Actually, this email was written by Theo to remind people that they were not to set the allowaperture variable except if they were using the X server. It makes sense to follow this advice even though the system is not running on a x86 architecture (the general feeling that the X server requires too many privileges is not limited to x86 architectures). However, as far as I know only x86 architectures are vulnerable to the SMM-based privilege escalation scheme.

Since the OS is not aware of the CPU switching to SMM, would it be possible writing a tool to warn, or even better block, an attempt to do so?

I don't think it would be a good idea for antivirus to block the CPU from switching to SMM on a computer where the motherboard requires the functionality. What can be done on compliant chipsets is to set the D_LCK bit as early as possible as boot time. But as I said before, it is not always possible. Another idea would be to check the integrity of the SMI handler. This would require antivirus to get a "trusted" version of the SMI handler binary, and to check from time to time that it was not silently modified. Of course, such a countermeasure would still be vulnerable to a "race condition", should the attacker be able to modify the SMI handler and deactivate the integrity check functionality before it can actually check the integrity of the handler.

Is setting the D_LCK bit going to stop "good" features from working too?

Well, it shouldn't. If the D_LCK bit is set, only the SMRAM control register becomes read only. So the processor can handle the SMI anyway. The only difference is that there is no way for software code to modify the default handler except for the handler itself. But again, the operating system is not supposed to modify this handler anyway. However Theo de Raadt told me he noticed that with some laptops, setting the D_LCK bit caused the system to hang or the APM and ACPI to stop working correctly.

Can we say that this is a hardware feature that can be misused by an attacker? Or should we say that the vulnerability is caused by a bad design of software?

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. So basically we use legal operations to get to higher privileges and to do something that is against the operating system security policy. So who's to blame? The processor for being able to switch to SMM? The chipset for providing the SMRAM control register? The operating system for providing system calls and pseudo-files that allow userspace code to switch the processor to SMM using hardware mechanisms?

My opinion is that operating system designers (OpenBSD designers for instance) have been aware that delegating Programmed IO access to userspace code could lead to potential security problems. The trouble is that they were forced to provide ways to delegate Programmed IO privileges because such applications as the X server require such mechanisms.

Most of the time, the X server seems to be the only ring 3 application which requires to access Programmed I/O ports. If the X server (or any other application that requires PIO accesses) did not require such privileges, the operating system would not need to provide ways of delegating PIO accesses to userspace. And the overall security level of the system would be much higher.

How can this vulnerability be mitigated?

Concerning the particular proof of concept attack scheme on OpenBSD, a short term solution would be for system administrators to decide that the X server should not be used and to set the machdep.allowaperture variable to 0. Another possible short term solution would be for BIOS manufacturers to set the D_LCK bit of the SMRAM control register of the chipset in the early stages of the boot sequence. This would prevent attackers from being able to run random code in System Management Mode.

But I think the SMM-based privilege escalation scheme is only an example of what can be done with Programmed I/O privileges. Thus we should tackle the core of the problem. And the best solution by far would be for X designers to move the X server to a safer model. For instance, the X server could be split into two different parts. One of them (the one requiring PIO accesses or important privileges on the hardware) could run in kernel mode, providing an abstraction layer to the other one remaining in userspace. The part remaining in userspace would no longer require any particular privilege. As I said, the X server is the only widespread userspace component that requires such privileges as Programmed I/O access. So when the X server moves to a safer model, operating systems will be able to finally dispose of Programmed I/O delegation system calls in their default configuration. I think it is a urgent matter for true security will never be achieved otherwise.

This article originally appeared in Security Focus.

Copyright © 2006, SecurityFocus

Federico Biancuzzi is a freelancer. In addition to SecurityFocus he also writes for ONLamp, LinuxDevCenter, and NewsForge.

Sponsored: Minds Mastering Machines - Call for papers now open

Biting the hand that feeds IT © 1998–2018