Feeds

The quest for ring zero

'One ring to rule them all...'

Using blade systems to cut costs and sharpen efficiencies

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.

Boost IT visibility and business value

More from The Register

next story
Secure microkernel that uses maths to be 'bug free' goes open source
Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit
14 antivirus apps found to have security problems
Vendors just don't care, says researcher, after finding basic boo-boos in security software
Only '3% of web servers in top corps' fully fixed after Heartbleed snafu
Just slapping a patched OpenSSL on a machine ain't going to cut it, we're told
How long is too long to wait for a security fix?
Synology finally patches OpenSSL bugs in Trevor's NAS
Israel's Iron Dome missile tech stolen by Chinese hackers
Corporate raiders Comment Crew fingered for attacks
Roll out the welcome mat to hackers and crackers
Security chap pens guide to bug bounty programs that won't fail like Yahoo!'s
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
Researcher sat on critical IE bugs for THREE YEARS
VUPEN waited for Pwn2Own cash while IE's sandbox leaked
prev story

Whitepapers

Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
Application security programs and practises
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Securing Web Applications Made Simple and Scalable
Learn how automated security testing can provide a simple and scalable way to protect your web applications.