csw06 duflot

Security Issues Related to Pentium System Management Mode: 

Security Issues Related to Pentium System Management Mode Loïc Duflot Direction Centrale de la Sécurité des Systèmes d’Information loic.duflot@sgdn.pm.gouv.fr SGDN/DCSSI 51 boulevard de la Tour Maubourg 75007 Paris

Outline: 

Outline Introduction PC architecture and I/O access Using System Management Mode to Circumvent Operating System Security A sample exploit on OpenBSD systems Conclusions

Introduction: 

Introduction Pentium System Management mode can be used to circumvent operating system security mechanisms. An example of how hardware functionalities can be misused by an attacker as a means for privilege escalation. Only legal and documented functionalities are used in the privilege escalation scheme. A generic approach…: Pentium®, P6 (Pentium® IV, Xeon®), Pentium® clones. … whenever the functionality exists. (some chipset do not implement SMM-related functionalities)

Outline: 

Outline Introduction PC architecture and I/O access Using System Management Mode to Circumvent Operating System Security A sample exploit on OpenBSD systems Conclusions

Simplified Pentium 4 architecture: 

Simplified Pentium 4 architecture Ethernet USB IDE LPC PCI Hub Link Front Side Bus RAM Display Adapter Processor North- Bridge Southbridge Chipset

I/O ports access: 

I/O ports access I/O access mechanisms: Memory mapped I/O (MMIO) I/O registers are mapped in physical address space. Programmed I/O (PIO) I/O registers are mapped on a separate 16-bit bus. Direct Memory Access (DMA) Peripherals act as masters on the PCI bus. IRQ to the processor. Unidirectional. Asynchronous.

Four modes of operation: 

Four modes of operation Protected Mode Virtual 8086 Mode Real Address Mode System Management Mode SMI rsm PE=0 or reset PE=1 VM=0 or Int. VM=1 reset SMI SMI rsm rsm or reset

Protected mode: 

Protected mode Hardware security mechanisms: Privilege rings: Most privileged: Ring 0 (kernel execution) Least privileged: Ring 3 (user space code) Segmentation and Paging. Hardware-based memory protection checks. Restricted instructions (HLT, LGDT, INVD). Mode of execution of most operating systems (Windows, Linux, OpenBSD…)

Protecting memory: Hardware mechanisms: 

Protecting memory: Hardware mechanisms Segmentation: Privilege rings Segment access restrictions (type and DPL) Paging (when enabled): User/supervisor bit Read/Write bit No eXecute/ eXecute Disable bit Quite a few security techniques (W^X, PaX…) rely upon such mechanisms.

Programmed I/O access: 

Programmed I/O access Two different hardware mechanisms: Set IOPL bits. (EFLAGS register) Clear bits in the I/O bitmap of the current hardware task. -andgt; Two different system calls: iopl (i386_iopl, /dev/io and the like) ioperm (i386_set_ioperm and the like)

System Management mode: 

System Management mode Maintenance mode: Used for efficient power management. Run specific proprietary code. SMI SMI SMI SMI RSM instruction SMM Back to calling context Assert a 'System Management Interrupt' (SMI) from any other mode: Thermal Sensor Century Rollover RTC Alarm TCO, USB

Generating the SMI: 

Generating the SMI

System Management mode: 

System Management mode A separate execution space: Every processor register is saved upon assertion of the SMI. The context (state) will be restored upon execution of « RSM ». In SMM: Free access to all physical memory. Free access to all Programmed I/O ports.

Memory in SMM: 

Memory in SMM 16-bit mode. All 4 Gb of physical memory may be accessed. Real mode addressing style. (20-bit) But: segment limits are extended to 4 Gb. And: 32-bit operand-size override prefixes may be used.

Real Address mode: 

Real Address mode 16-bit mode: 1 Mb address space Address Translation: Segment:Offset = Segment andlt;andlt;4 + Offset Example: 0xA000:0x8000 = 0xA8000 Mostly used: At startup and shutdown time. May be used to benefit from BIOS functionalities. Transitions to protected mode unrestricted. Transitions from protected mode restricted. A 8086 processor just a little faster!

Virtual 8086 mode: 

Virtual 8086 mode Virtual mode embedded into protected mode. Ring 3 execution context. Simulate the behavior of a 8086 processor. Paging may be used. 16-bit mode. Access is only allowed during hardware task switch or interrupt handling.

Memory Protection: 

Memory Protection So Paging and Segmentation security mechanisms only exist in Protected Mode. 'PaX/Segmexec prevent introduction/execution of arbitrary code'. Well that’s not true outside of protected mode!!! But that’s ok because there is no way to switch to other modes from userspace, right?

Outline: 

Outline Introduction PC architecture and I/O access Using System Management Mode to Circumvent Operating System Security A sample exploit on OpenBSD systems Conclusions

SMRAM: 

SMRAM SMBASE + 0xFFFF SMBASE + 0xFE00 SMBASE +0x8000 SMBASE SMRAM First SMI Handler instruction Processor context prior SMI assertion Code, Heap and Stack State save area Physically localized in unused memory blocks SMBASE + 0x1FFFF Usually SMBASE=0xA0000 Intel processor doc: SMBASE=0x30000 Intel Chipset doc: SMBASE=0xA0000

State Save Area Map: 

State Save Area Map Instruction pointer IOPL bits Code segment Task register Stack pointer

Accessing SMRAM: 

Access to physical address 0xA8000 Accessing SMRAM Ethernet USB IDE LPC PCI Hub Link RAM (including SMRAM) Display Adapter Processor North- Bridge Southbridge

SMRAM control register: 

SMRAM control register D_CLOSE D_OPEN D_LCK Enable Reserved 7 0 Chipset-specific SMRAM control register: 8-bit register D_LCK: Locks SMRAM control register. D_OPEN: Enables all SMRAM accesses even if not in SMM. D_CLOSE: No data type accesses to SMRAM space. Enable: Enables SMM functionalities Read-Only

Possible attack scheme: 

Possible attack scheme Enable System Management Interrupts. Open SMRAM space. Replace default SMI Handler by custom one. Close SMRAM space. Trigger SMI. Gain access to restricted operations.

Required privileges: 

Required privileges I/O access privileges on the SMRAM control register. I/O access privileges on at least one of the I/O registers that can trigger the SMI. Optional I/O access to corresponding SMI-enable registers. Write access to SMRAM (0xA0000-BFFFFF) -andgt; Write access to the legacy video RAM.

Outline: 

Outline Introduction PC architecture and I/O access Using System Management Mode to Circumvent Operating System Security A sample exploit on OpenBSD systems Conclusions

OpenBSD: 

OpenBSD Security-aware operating system. Proactive security. Memory protection: W^X, guard pages, randomized malloc() and mmap(), etc... Secure levels.

OpenBSD: 

OpenBSD The Secure Levels:

Physical Memory Access: 

Physical Memory Access On OpenBSD-based systems: If securelevel andgt;0 /dev/mem and /dev/kmem cannot be written to. This means that even root cannot directly write to physical memory. And yet, the display server (X) needs to be able to map MMIO devices.

/dev/xf86: 

/dev/xf86 Use of the /dev/xf86 pseudo-file. /dev/mem but only in video memory areas. May be opened at most once (at a time). Cannot be opened if the machdep.allowaperture variable is set to 0.

Allowaperture: 

Allowaperture If set access to /dev/xf86 is allowed. Otherwise prevents access to both /dev/xf86 and i386_iopl() (and i386_set_ioperm).

Programmed I/O ports access: 

Programmed I/O ports access On OpenBSD two different system calls are available: i386_iopl i386_set_ioperm + Linux (linux_sys_iopl, linux_sys_ioperm) and FreeBSD (KDENABIO ioctl) compatibility system calls. But i386_set_ioperm cannot be used to request access to ports 0xcfc and 0xcf8. i386_iopl and i386_set_ioperm restricted to superuser-owned processes.

A sample exploit against OpenBSD: 

A sample exploit against OpenBSD We assume that the target system is running OpenBSD in Highly Secure mode with allowaperture=1. We assume that an attacker has found a way to execute code with superuser privileges. Thus, the attacker may use the i386_iopl call (unrestricted Programmed I/O access) and write to the /dev/xf86 device (write access to the 0xA0000-0xBFFFF memory range). But the attacker still lacks a way to get to kernel (ring 0 random code execution) privileges…

Sample proof-of-concept exploit: 

Sample proof-of-concept exploit A root in highly secure mode (or secure level) to kernel privilege escalation scheme. Aim: For example, lower the securelevel to « Permanently insecure ». Bonus: Modification of the EIP register while in SMM. Experimentations carried out on a PC equipped with a Pentium® 4, and a Intel® MCH/GMCH-ICH2/ICH5 chipset.

1st step: Locating the securelevel variable: 

1st step: Locating the securelevel variable Virtual address: nm /bsd | grep securelevel. Physical Address: Virtual memory space Physical memory space Kernel Kernel 0 0 4Go 4Go 0xd0000000 offset Example on OpenBSD 3.5

2nd Step: Craft Handler: 

2nd Step: Craft Handler

3rd Step: Default Handler Replacement: 

3rd Step: Default Handler Replacement

Last step: SMI generation: 

Last step: SMI generation

Did it work?: 

Did it work? Return to protected mode overwrites EIP with the address of the test function. The program displays that the secure level has been lowered. This proves that we had successfully gone into SMM. Check that the secure level was lowered.

Possible countermeasures: 

Possible countermeasures Decision from the system administrator: decide that the X server will not be used. machdep.allowaperture = 0 Patch the BIOS or the OS: Set the D_LCK bit in the early boot stages. Prevent access to the SMRAM register: Programmed I/O filter. No IOPL, I/O Bitmap management only. No PIO accesses from ring 3 code.

Outline: 

Outline Introduction PC architecture and I/O access Using System Management Mode to Circumvent Operating System Security A sample exploit on OpenBSD systems Conclusions

Efficiency of the attack: 

Efficiency of the attack

Privilege escalation: 

Privilege escalation On most systems, being able to carry out this scheme means being granted superuser privileges. On OpenBSD, root is only granted limited privileges. That is why the attack scheme is effective. There may be easier ways to bypass the Secure Level mechanism. But more than the result, the attack scheme in itself is interesting: unused, legacy or routinely used functionalities can be used from userspace to circumvent operating system security functions. One of the problems is X requiring too many privileges.

Conclusion: 

Conclusion Only documented functionalities of the Pentium® processor and its chipset were used… … and yet we have been able to circumvent operating system security functions. Would this point to a consistency issue in hardware and OS security models? IOPL and I/O privileges at stake. This demonstrates the need for trust in, and wise use of, hardware components.

Any questions?: 

Any questions? Thank you! loic.duflot@sgdn.pm.gouv.fr Joint work with: Olivier Grumelard (SGDN/DCSSI) Daniel Etiemble (Paris XI University, LRI)