Feeds

The quest for ring zero

'One ring to rule them all...'

  • alert
  • submit to reddit

SANS - Survey on application security programs

Can you provide a summary of an attack vector?

To sum up what has been said so far, if the chipset encompasses such a "SMRAM control register", the contents of the default SMI handler can be modified at will by software code (with PIO access privileges and write access to the video RAM range). PIO accesses are required to set and clear the D_OPEN bit so that the SMRAM can be accessed while in protected mode. Write access to the video RAM range is compulsory to modify the default SMI handler. Also, a SMI can be generated by accessing PIO registers. So software code with the required privileges can modify the SMI handler at will and trigger the SMI to get full control over the system. It should be clearly noted that this does not require any physical access of any kind to the target system.

The goal of the attack seems to be enabling SMM. To do this in a previous example with OpenBSD, you said that you needed root privileges, and then you took advantage of X Window permissions. Was this path just one way to exploit the flaw, or do you think this is the only way?

It is not exactly true to say that to carry out the attack scheme the attacker requires root privileges. To carry out the general privilege escalation scheme, the attacker needs write access to various Programmed I/O registers and write access to the legacy video RAM range (0xA0000-0xbffff).

So we can assume that, on any system where a process or a set of processes is delegated such privileges, there will always be a way for attackers to exploit the flaw. The "root to kernel" proof of concept scheme on OpenBSD is really only an example. On OpenBSD (as well as on other systems) the X server requires way too many privileges (those required to be able to use the privilege escalation scheme and more). So it seems fair to assume that a vulnerability in the X server could be exploited by remote or local attackers to reach kernel privileges using the general privilege escalation scheme I depicted.

OpenBSD uses a privilege separated Xorg server. Would it stop the attack of a not-root user?

I think this kind of privilege separation is designed exactly to restrict the efficiency of such attacks. If the vulnerability is in the not-privileged part of the X server, it cannot be used to carry out SMM-based attack schemes.

If I'm using the account "simple-user" on a vulnerable hardware running GNU/Linux and XWindows, would I be able to use the privileges of my X processes to launch an attack?

On a Linux system running XWindows, it is theoretically possible for a "simple-user" account to use the privileges of X to launch an attack. The most simple way to do so would be to exploit an hypothetical [not so hypothetical, note from the interviewer] bug in the X server to get to execute random code with X server privileges. Another possibility would be to trick a vulnerability-free X server into accessing SMRAM while it believes it is actually modifying video RAM. This kind of attack seems quite complicated (the most difficult part would be to get the X server to modify the setting of the D_OPEN bit in the chipset) and no such attack has been proved to work at the time.

Why should I use your technique if I'm already root? What should I like to do on that box?

On most existing systems the superuser is granted far too many privileges. On most Linux systems, processes running under root identity can pretty easily escalate to kernel (ring 0 random code execution) privileges. It is the same for administrators on Windows systems. But why should it be so? After all the superuser is only a user (with other privileges than normal users) on the system. So why should he need to modify the inner structure of the operating system? The superuser could for instance only be authorized to modify some system settings.

In fact, many systems offer means of reducing superuser privileges. System administrators may be trusted, but what happens in case of when the superuser account is compromised? OpenBSD designers, for instance, perfectly understood the necessity of restricting superuser privileges. They chose to use the securelevel to do so. The securelevel has really been designed as the last line of defense against a possible compromise of the root account. Securelevel aims to reduce superuser privileges so that it is virtually impossible, even for the superuser, to modify the core of the operating system.

Apart from the secure level mechanism, POSIX capabilities or security labels, that attempt to minimise or separate privileges granted to system- or superuser-owned tasks, should be mentioned. On system using such mechanisms, it is meaningful for an attacker to go from reduced root privileges to kernel privileges. Moreover getting to kernel privileges allows an attacker to load rootkits that will better conceal his actions on the systems, making it harder to identify the system as compromised or to restore it.

In situations where the display server is to be used (i.e. where the machdep.allowaperture variable of the OpenBSD kernel is non-zero), the securelevel mechanism is one of those protections that can be circumvented using the attack scheme from the CanSecWest presentation [PPT].

When you are in SMM, could you read/write the BIOS code, config and passwords?

When the attacker switches the processor to SMM, he can write or read any area in physical memory that is reported as writable/readable by the chipset. This means for instance that he can access the BIOS. So there is no way to prevent the attacker from updating the BIOS (except if it is stored in ROM) if he wants to. But remember that updating the BIOS is not a trivial operation. The attacker has to know how it is done and what he wants to modify.

Can we use SMM to bypass barriers among systems placed by virtualization software such as VMWare or Xen or OpenVZ/Virtuozzo?

That is definitely something that crossed my mind several times. My intuition is that it is possible to bypass virtualisation barriers each time the virtual domain is granted PIO access privileges. I checked that the attack scheme did not work against Xen 2.0 some time ago. Basically, PIO accesses are not possible from invited domains except from domain0. So the attack scheme does not work from domains other than domain0. Domain0 is supposed to be a privileged and trusted domain anyway.

Though it might not be the simplest way to do this, attack schemes using PIO accesses can also theoretically be used to bypass chroot barriers.

Such as a FreeBSD Jail?

On FreeBSD, system calls that grant I/O access permissions are restricted to non-jailed superusers. Therefore, a jailed process should not be able to get the prerequisites for this attack scheme.

Combat fraud and increase customer satisfaction

More from The Register

next story
Parent gabfest Mumsnet hit by SSL bug: My heart bleeds, grins hacker
Natter-board tells middle-class Britain to purée its passwords
Samsung Galaxy S5 fingerprint scanner hacked in just 4 DAYS
Sammy's newbie cooked slower than iPhone, also costs more to build
Obama allows NSA to exploit 0-days: report
If the spooks say they need it, they get it
Web data BLEEDOUT: Users to feel the pain as Heartbleed bug revealed
Vendors and ISPs have work to do updating firmware - if it's possible to fix this
Snowden-inspired crypto-email service Lavaboom launches
German service pays tribute to Lavabit
One year on: diplomatic fail as Chinese APT gangs get back to work
Mandiant says past 12 months shows Beijing won't call off its hackers
Call of Duty 'fragged using OpenSSL's Heartbleed exploit'
So it begins ... or maybe not, says one analyst
NSA denies it knew about and USED Heartbleed encryption flaw for TWO YEARS
Agency forgets it exists to protect communications, not just spy on them
prev story

Whitepapers

Designing a defence for mobile apps
In this whitepaper learn the various considerations for defending mobile applications; from the mobile application architecture itself to the myriad testing technologies needed to properly assess mobile applications risk.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.