The quest for ring zero

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.