Memory Corruption: from sandbox to SMM
-
Upload
positive-hack-days -
Category
Technology
-
view
1.832 -
download
1
Transcript of Memory Corruption: from sandbox to SMM
![Page 1: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/1.jpg)
Memory Corruption: from sandbox to SMM
Nikita TarakanovSecurity Center of Excellence
Oleksandr Bazhaniuk, Yuriy Bulygin, Andrew Furtak, Mikhail Gorobets, John Loucaides, Alexander Matrosov, Mickey Shkatov
Advanced Threat Research (www.intelsecurity.com/atr)
Positive Hack Days 2015
Moscow, Russia
![Page 2: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/2.jpg)
Agenda
• Introduction
• Memory Corruption: Ring3 -> Ring0
• Memory Corruption: Ring0 -> SMM
• Q&A
![Page 3: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/3.jpg)
Introduction
• Ring3(IE, Adobe Reader, Flash player, MS Office etc) applications as first attack vector• Not privileged level• Sandboxes (IE EPM, Reader sandbox, Chrome sandbox etc)• Need to get Ring0 to have ability to make fancy stuff• So, Elevation of Privileges (R3->R0) Exploits/Vulnerabilities are critical• Good examples: pwn2own 2013/2014 IE EPM sandbox escapes via
kernel exploit• Ring0 is powerful, but there is more privileged mode - SMM
![Page 4: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/4.jpg)
Memory Corruption: Ring3 -> Ring0
![Page 5: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/5.jpg)
Memory Corruption types: Ring3 -> Ring0
• Stack-based buffer overflow – rare, out-of-scope
• Pool overflow
• Arbitrary memory corruption
![Page 6: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/6.jpg)
Memory Corruption: Ring0 mitigations
• Various security checks: Stack-canary, Pool metadata integrity checks
• KASLR
• SMEP
• SMAP
![Page 7: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/7.jpg)
Memory Corruption: Pool overflow
![Page 8: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/8.jpg)
Techniques to exploit pool overflows
• Pool metadata corruption
• Object metadata corruption (DKOHM)
• Object Type Confusion (DKOHM + DKOM)
![Page 9: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/9.jpg)
Object Metadata
• OBJECT_HEADER
• Optional headers
POOL_HEADER
Optional Headers
OBJECT_HEADER
Object
![Page 10: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/10.jpg)
OBJECT_HEADER
• • kd> dt nt!_OBJECT_HEADER• • +0x000 PointerCount : Int4B • • +0x004 HandleCount : Int4B • • +0x004 NextToFree : Ptr32 Void • • +0x008 Lock : _EX_PUSH_LOCK • • +0x00c TypeIndex : UChar <- Index of pointer to OBJECT_TYPE structure in ObTypeIndexTable• • +0x00d TraceFlags : UChar • • +0x00d DbgRefTrace : Pos 0, 1 Bit • • +0x00d DbgTracePermanent : Pos 1, 1 Bit • • +0x00e InfoMask : UChar • • +0x00f Flags : UChar • • +0x010 ObjectCreateInfo : Ptr32 _OBJECT_CREATE_INFORMATION • • +0x010 QuotaBlockCharged : Ptr32 Void • • +0x014 SecurityDescriptor : Ptr32 Void • • +0x018 Body : _QUAD
![Page 11: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/11.jpg)
ObTypeIndexTable
• • kd> dd nt!ObTypeIndexTable L40• • 81a3edc0 00000000 bad0b0b0 8499c040 849aa390 • • 81a3edd0 84964f70 8499b4c0 84979500 84999618 • • 81a3ede0 84974868 849783c8 8499bf70 84970b40 • • 81a3edf0 849a8888 84979340 849aaf70 849a6a38 • • 81a3ee00 8496df70 8495b040 8498cf70 84930a50 • • 81a3ee10 8495af70 8497ff70 84985040 84999e78 • • 81a3ee20 84997f70 8496c040 849646e0 84978f70 • • 81a3ee30 8497aec0 84972608 849a0040 849a9750 • • 81a3ee40 849586d8 84984f70 8499d578 849ab040 • • 81a3ee50 84958938 84974a58 84967168 84967098 • • 81a3ee60 8496ddd0 849a5140 8497ce40 849aa138 • • 81a3ee70 84a6c058 84969c58 8497e720 85c62a28 • • 81a3ee80 85c625f0 00000000 00000000 00000000
![Page 12: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/12.jpg)
OBJECT_TYPE
• kd> dt nt!_OBJECT_TYPE• +0x000 TypeList : _LIST_ENTRY• +0x008 Name : _UNICODE_STRING• +0x010 DefaultObject : Ptr32 Void• +0x014 Index : UChar• +0x018 TotalNumberOfObjects : Uint4B• +0x01c TotalNumberOfHandles : Uint4B• +0x020 HighWaterNumberOfObjects : Uint4B• +0x024 HighWaterNumberOfHandles : Uint4B• +0x028 TypeInfo : _OBJECT_TYPE_INITIALIZER• +0x080 TypeLock : _EX_PUSH_LOCK• +0x084 Key : Uint4B• +0x088 CallbackList : _LIST_ENTRY
![Page 13: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/13.jpg)
Procedures
• kd> dt nt!_OBJECT_TYPE_INITIALIZER• [..]• +0x030 DumpProcedure : Ptr32 void • +0x034 OpenProcedure : Ptr32 long • +0x038 CloseProcedure : Ptr32 void • +0x03c DeleteProcedure : Ptr32 void • +0x040 ParseProcedure : Ptr32 long • +0x044 SecurityProcedure : Ptr32 long • +0x048 QueryNameProcedure : Ptr32 long • +0x04c OkayToCloseProcedure : Ptr32 unsigned char
![Page 14: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/14.jpg)
ObTypeIndexTable & Object Type
Object HeaderTypeIndex
Pointer to OBJECT_TYPE
ObTypeIndexTable OBJECT_TYPE
Pointers to various procedures
Object’s dispatch function
![Page 15: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/15.jpg)
Object Type Index Table (x86)
![Page 16: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/16.jpg)
Object Type Index Table (x64)
![Page 17: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/17.jpg)
Object metadata corruption (DKOHM)
POOL_HEADER
Optional Headers
OBJECT_HEADER
Object
overflow
ObTypeIndexTable
0x00000000
0xBAD0B0B0Fake OBJECT_TYPE
Shellcode
![Page 18: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/18.jpg)
Windows 8.1
• 0xBAD0B0B0 has gone
![Page 19: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/19.jpg)
Object Type Confusion (DKOHM + DKOM)
• Set TypeIndex value to different object type (object type confusion)
• Object Manager is fooled (before it was Type A, not it’s Type B)
• Craft malicious object’s data (counters, pointers)
• Invoke system service(s) to trigger access to malicious object
• Profit
![Page 20: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/20.jpg)
Object data corruption (DKOHM + DKOM)
Object Header
Object Data
ObTypeIndexTable
FILE OBJECT_TYPE
ALPC OBJECT_TYPE
![Page 21: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/21.jpg)
Object data corruption (DKOHM+DKOM)
Object Header FILE_OBJECT
Object Header ALPC_OBJECT(all data is under control)
exploit
Invoke system service trigger access to object
Different scenarios
After overwrite -> type confusion
![Page 22: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/22.jpg)
OBJECT_TYPE_INITIALIZER Procedures• +0x030 DumpProcedure : (null) • +0x038 OpenProcedure : (null) • +0x040 CloseProcedure : 0xfffff801`5b913b44 void nt!
ObpCloseDirectoryObject+0• +0x048 DeleteProcedure : 0xfffff801`5b92743c void nt!
ObpDeleteDirectoryObject+0• +0x050 ParseProcedure : (null) • +0x058 SecurityProcedure : 0xfffff801`5b848e54 long nt!
SeDefaultObjectMethod+0• +0x060 QueryNameProcedure : (null) • +0x068 OkayToCloseProcedure : (null)
![Page 23: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/23.jpg)
OBJECT_TYPE_INITIALIZER Procedures• +0x030 DumpProcedure : (null) • +0x038 OpenProcedure : (null) • +0x040 CloseProcedure : (null) • +0x048 DeleteProcedure : 0xfffff801`5b9250fc void nt!IopDeleteDevice+0• +0x050 ParseProcedure : 0xfffff801`5b86dde0 long nt!IopParseDevice+0• +0x058 SecurityProcedure : 0xfffff801`5b842028 long nt!
IopGetSetSecurityObject+0• +0x060 QueryNameProcedure : (null) • +0x068 OkayToCloseProcedure : (null)
![Page 24: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/24.jpg)
Object Type Confusion
Object Header Event Object
Object Header FILE_OBJECT(all data is under control)
exploit nt!IopGetSetSecurityObject
NtQuerySecurityObject
After overwrite -> type confusion
nt!SeDefaultObjectMethod
![Page 25: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/25.jpg)
SecurityProcedure vector
• For most object types: nt!SeDefaultObjectMethod
• WmiGuid object type: nt!WmipSecurityMethod
• File/Device object type: nt!IopGetSetSecurityObject
• Key object type: nt!CmpSecurityMethod
![Page 26: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/26.jpg)
nt!IopGetSetSecurityObject
• FILE_OBJECT -> DEVICE_OBJECT -> DRIVER_OBJECT
-> MAJOR_ROUTINE -> attacker’s shellcode
• Execution Hijack by three consequent dereferences!!!!
![Page 27: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/27.jpg)
nt!IopGetSetSecurityObject
![Page 28: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/28.jpg)
nt!IopGetSetSecurityObject chain
• 0: kd> dt nt!_FILE_OBJECT• +0x000 Type : Int2B• +0x002 Size : Int2B• +0x008 DeviceObject : Ptr64 _DEVICE_OBJECT• 0: kd> dt nt!_DEVICE_OBJECT• +0x000 Type : Int2B• +0x002 Size : Uint2B• +0x004 ReferenceCount : Int4B• +0x008 DriverObject : Ptr64 _DRIVER_OBJECT
![Page 29: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/29.jpg)
nt!IopGetSetSecurityObject chain
• 0: kd> dt nt!_DRIVER_OBJECT• +0x000 Type : Int2B• +0x002 Size : Int2B• +0x008 DeviceObject : Ptr64 _DEVICE_OBJECT• +0x010 Flags : Uint4B• +0x018 DriverStart : Ptr64 Void• +0x020 DriverSize : Uint4B• +0x028 DriverSection : Ptr64 Void• +0x030 DriverExtension : Ptr64 _DRIVER_EXTENSION• +0x038 DriverName : _UNICODE_STRING• +0x048 HardwareDatabase : Ptr64 _UNICODE_STRING• +0x050 FastIoDispatch : Ptr64 _FAST_IO_DISPATCH• +0x058 DriverInit : Ptr64 long • +0x060 DriverStartIo : Ptr64 void • +0x068 DriverUnload : Ptr64 void • +0x070 MajorFunction : [28] Ptr64 long
![Page 30: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/30.jpg)
Close/Delete Procedure vector
• Huge amount of different execution flows: 56 functions
• Mostly arbitrary memory overwrite
• Some adjacent read/write
• Some hijack of execution flow
![Page 31: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/31.jpg)
Other Procedures
• DumpProcedure, OpenProcedure, ParseProcedure,
QueryNameProcedure, OkayToCloseProcedure
• Are rare – no interest in here
![Page 32: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/32.jpg)
Object’s body vector (DKOM)
• There are several typical OOP interfaces• Constructor – NtCreate* (NtCreateFile)• Destructor – NtClose• Getter – NtQueryInformation* (NtQueryInformationWorkerFactory)• Setter – NtSetInformation* (NtSetInformationKey)• Object Type specific: NtClearEvent, NtAlpcAcceptConnectPort,
NtEnumerateValueKey, NtRecoverResourceManager etc
![Page 33: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/33.jpg)
DKOHM+DKOM restrictions
• Unfortunately you cant freely use Getter/Setter/Specific when you change type of an object – caused by ValidAccessMask field • +0x010 Name : _UNICODE_STRING "WindowStation“• +0x01c ValidAccessMask : 0xf037f
• +0x010 Name : _UNICODE_STRING "Directory“• +0x01c ValidAccessMask : 0xf000f
• But you can still smash object’s data without changing object type
![Page 34: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/34.jpg)
DKOHM+DKOM restrictions
• Some Object Types have same ValidAccessMask• +0x010 Name : _UNICODE_STRING "Section“• +0x01c ValidAccessMask : 0x1f001f
• +0x010 Name : _UNICODE_STRING "Job“• +0x01c ValidAccessMask : 0x1f001f
• So technique using Getter/Setter/Specific is possible, but limited
![Page 35: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/35.jpg)
Symbolic Link: Getter vector NtQuerySymbolicLinkObject
![Page 36: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/36.jpg)
Directory Object: Getter vector NtQueryDirectoryObject• Up-to 0x25 times of reading arbitrary memory
![Page 37: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/37.jpg)
WorkerFactory object Getter:NtQueryInformationWorkerFactory
![Page 38: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/38.jpg)
WorkerFactory object Setter:NtSetInformationWorkerFactory
![Page 39: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/39.jpg)
Memory Corruption: Ring3 -> Ring0
• So we have all primitives:
• Arbitrary Memory Overwrite -> store payload in kernel executable memory
• Arbitrary Memory Read -> KASLR bypass
• Arbitrary Code Execution -> execution with Ring0 privileges
![Page 40: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/40.jpg)
Memory Corruption: Ring0 -> SMM
![Page 41: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/41.jpg)
System Management Mode (SMM)
• System Management Interrupt (SMI)• CPU (OS) state is saved in SMRAM upon entry to SMM and restored upon exit from SMM• SMI handlers are invoked by CPU upon System Management Interrupt (SMI) from chipset or other logical CPUs and
execute in System Management Mode (SMM) of x86 CPU• SMI handlers return to the OS using RSM instruction
• SMRAM is a range of DRAM reserved by BIOS SMI handlers• Protected from software and device acces
![Page 42: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/42.jpg)
System Management Interrupt (SMI) Handlers
SMRR_PHYSBASE
SMRAM
0x00000000
0xFFFFFFFF
SMI handlers
SMM state save area
SMBASE + 8000h
SMBASE
SMBASE + FFFFh
SMRAM
![Page 43: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/43.jpg)
System Management Interrupt (SMI) Handlers• SMM handler execution environment:• At entry, CS = SMBASE (0x30000 at reset), EIP=0x8000• Addressable physical space from 0 to 0xFFFFFFFFh (4G) • No paging• All hardware interrupts are disabled
SMM Core dispatcherSMI
SMST
CPU info
Memory info
I/O info
SMM Driver
SMM Driver
SMM Driver
SMM callback
SMM callback
SMM callback...
RSM
SMM code flow
![Page 44: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/44.jpg)
Trigger ‘SW’ SMI via APMC I/O Port• _swsmi PROC• ..
• ; setting up GPR (arguments) to SMI handler call• ; AX gets overwritten by _smi_code_data (which is passed in RCX)• ; DX gets overwritten by the value of APMC port (= 0x00B2)• mov rax, rdx ; rax_value• mov ax, cx ; smi_code_data• mov rdx, r10 ; rdx_value• mov dx, 0B2h ; APMC SMI control port 0xB2
• mov rbx, r8 ; rbx_value• mov rcx, r9 ; rcx_value• mov rsi, r11 ; rsi_value• mov rdi, r12 ; rdi_value
• ; write smi_code_data value to SW SMI control/data ports (0xB2/0xB3)• out dx, ax
• ..• ret
• _swsmi ENDP
![Page 45: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/45.jpg)
Trigger ‘SW’ SMI using CHIPSEC• From command line:
• # chipsec_util.py smi smic smid [RAX RBX RCX RDX RSI RDI]
• From any module in CHIPSEC:
• self.intr = chipsec.hal.Interrupts( self.cs )
• self.intr.send_SW_SMI(smic,smid,rax,rbx,rcx,rdx,rsi,rdi)
![Page 46: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/46.jpg)
Known SMI Vulnerabilities
![Page 47: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/47.jpg)
Known Vulnerabilities Related to SMM
• Issue• When D_LCK is not set by BIOS, SMM space decode can be
changed to open access to CSEG when CPU is not in SMM: Using CPU SMM to Circumvent OS Security Functions
• Also Using SMM For Other Purposes• Mitigation• D_LCK bit locks down Compatible SMM space (a.k.a. CSEG)
configuration (SMRAMC)• SMRAMC[D_OPEN]=0 forces access to legacy SMM space
decode to system bus rather than to DRAM where SMI handlers are when CPU is not in System Management Mode (SMM)
• Check• chipsec_main –-module common.smm
Unlocked Compatible/Legacy SMRAM
![Page 48: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/48.jpg)
Known Vulnerabilities Related to SMM
• Issue• CPU executes from cache if memory type is cacheable• Ring0 exploit can make SMRAM cacheable (variable MTRR)• Ring0 exploit can then populate cache-lines at SMBASE with SMI
exploit code (ex. modify SMBASE) and trigger SMI• CPU upon entering SMM will execute SMI exploit from cache• Attacking SMM Memory via Intel Cache Poisoning• Getting Into the SMRAM: SMM Reloaded
• Mitigation• CPU System Management Range Registers (SMRR) forcing UC and
blocking access to SMRAM when CPU is not in SMM• Check• chipsec_main –-module common.smrr
SMRAM “Cache Poisoning” Attacks
![Page 49: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/49.jpg)
Legacy SMI Handlers Calling Out of SMRAM
• OS level exploit stores payload in F-segment below 1MB (0xF8070 Physical Address)
• Exploit has to also reprogram PAM for F-segment• Then triggers “SW SMI” via APMC port (I/O 0xB2)• SMI handler does CALL 0F000:08070 in SMM
• BIOS SMM Privilege Escalation Vulnerabilities (14 issues in just one SMI Handler)
• System Management Mode Design and Security Issues
Branch Outside of SMRAM
![Page 50: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/50.jpg)
Legacy SMI Handlers Calling Out of SMRAM
Phys MemorySMRAM
CALL F000:8070
Legacy BIOS Shadow(F/ E-segments)
PA = 0xF0000
1 MB
![Page 51: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/51.jpg)
Legacy SMI Handlers Calling Out of SMRAM
Phys MemorySMRAM
CALL F000:8070
Legacy BIOS Shadow(F/ E-segments)
PA = 0xF0000
1 MB
Code fetchin SMM
![Page 52: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/52.jpg)
Legacy SMI Handlers Calling Out of SMRAM
Phys MemorySMRAM
CALL F000:8070
Legacy BIOS Shadow(F/ E-segments)
PA = 0xF0000
1 MB
0xF8070: payload0F000:08070 = 0xF8070 PA
Code fetchin SMM
![Page 53: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/53.jpg)
Function Pointers Outside of SMRAM (DXE SMI)
Phys Memory
SMRAM
mov ACPINV+x, %rax
call *0x18(%rax)
ACPI NV Area
payload
1. Read function pointer from ACPI NVS memory (outside SMRAM)
Pointer to payload 2. Call function pointer (payload outside SMRAM)
Attacking Intel BIOS
![Page 54: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/54.jpg)
Mitigating SMM “Call-Outs”
• These issues are specific to particular SMI Handler implementation…• static analysis of binary?• run-time debugging?
• CPU Hardware Support (starting in Haswell)• SMM Code Access Check
• SMM_Code_Chk_En (SMM-RW)• This control bit is available onlyif MSR_SMM_MCA_CAP[58] == 1. • When set to ‘0’ (default) none of the logical processors are prevented from executing SMM
code outside the ranges defined by the SMRR. • When set to ‘1’ any logical processor in the package that attempts to execute SMM code not
within the ranges defined by the SMRR will assert an unrecoverable MCE.• Attempts to execute code outside SMRAM while inside SMM result in a Machine Check
Exception!
![Page 55: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/55.jpg)
Legacy SMI Handlers Calling Out of SMRAM
Phys MemorySMRAM
CALL F000:8070
Legacy BIOS Shadow(F/ E-segments)
PA = 0xF0000
1 MB
0xF8070: payload0F000:08070 = 0xF8070 PA
Code fetchin SMM – causes Machine Check Exception
![Page 56: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/56.jpg)
Function Pointers Outside of SMRAM (DXE SMI)
Phys MemorySMRAM
mov ACPINV+x, %rax
call *0x18(%rax)
ACPI NV Area
payload
1. Read function pointer from ACPI NVS memory (outside SMRAM)
Pointer to payload 2. Call function pointer (payload outside SMRAM) -- causes MCE!
![Page 57: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/57.jpg)
A new class of vulnerabilities in SMI handlers
![Page 58: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/58.jpg)
Pointer Arguments to SMI HandlersPhys Memory
SMI Handlers in SMRAM
OS Memory
SMI Handler writes result to a buffer at address passed in RBX…
RAX (code)
RBX (pointer)
RCX (function)
RDX
RSI
RDI
SMI handler specific structure
SMI
![Page 59: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/59.jpg)
Pointer VulnerabilitiesPhys Memory
SMI Handlers in SMRAM
OS Memory
Exploit tricks SMI handler to write to an address inside SMRAM
RAX (code)
RBX (pointer)
RCX (function)
RDX
RSI
RDI
Fake structure inside SMRAM
SMI
![Page 60: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/60.jpg)
What to overwrite inside SMRAM?• Depending on the vulnerability, caller may control address to write, the value written, or both.
• Often the caller controls the address but doesn’t have control over the values written to the address by the SMI handler
• In our example the attacker controls the address and does not control the value:
The SMI handler writes 0 value to the specified address
![Page 61: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/61.jpg)
What to overwrite inside SMRAM?• What can an exploit overwrite in SMRAM without crashing?• SMI Handler code starting at SMBASE + 8000h• Internal SMI handler’s state/flags inside SMRAM• Contents of SMM state save area at SMBASE + FC00h, where the CPU
state is stored on SMM entry
![Page 62: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/62.jpg)
What to overwrite inside SMRAM? • Current value of SMBASE MSR is also saved in SMM state save area by CPU at offset SMBASE + FEF8h upon SMI
• Stored value of SMBASE is restored upon executing RSM
• SMBASE relocation: SMI handler may change the saved value of SMBASE in order to change the location of SMRAM upon next SMI
• The idea:Move SMBASE to a new, unprotected location by changing the SMBASE value stored in the SMM state save area.
![Page 63: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/63.jpg)
How do we know where to write?SMM state save is at SMBASE + FC00h
But SMBASE is not known• SMBASE MSR can be read only in SMM• SMBASE is different per CPU thread• SMBASE is different per BIOS implementation
SMBASE should be programmed at some offset from TSEG/SMRR_PHYSBASE
![Page 64: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/64.jpg)
How do we know where to write?1. Dump contents of SMRAM• Use hardware debugger• Use similar “pointer read” vulnerability• Use another vulnerability (e.g. S3 boot script) to disable SMRAM DMA
protection and use DMA via graphics aperture to read SMRAM And in the dump look for SMI handler entry point code Known values in GP registers (invoke SMI with these values before dump)
2. Read SPI flash memory & RE initialization code to find SMBASE there.3. Guess location of SMBASE:• SMBASE = SMRR_PHYSBASE• SMBASE = SMRR_PHYSBASE - 8000h (SMRR_PHYSBASE at SMI handler location)• Blind iteration through all offsets within SMRAM as potential saved SMBASE
value
![Page 65: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/65.jpg)
How does the attack work?Phys Memory
SMI Handler
OS Memory
• CPU stores current value of SMBASE in SMM save state area on SMI and restores it on RSM
RAX (code)
RBX (pointer)
RCX (function)
SMI handler specific structure
SMI
SMBASE
SMM State Save AreaSaved SMBASE value
SMI Entry Point (SMBASE + 8000h)
![Page 66: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/66.jpg)
How does the attack work?Phys Memory
SMI Handler
OS Memory
• Attacker prepares fake SMRAM with new SMI handler outside of SMRAM at some address (PA 0) that will be a new SMBASE
Fake SMI handler
SMBASE
Saved SMBASE value SMM State Save Area
SMI Entry Point (SMBASE + 8000h)
![Page 67: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/67.jpg)
How does the attack work?Phys Memory
SMI Handler
OS Memory
• Attacker triggers SMI w/ RBX pointing to saved SMBASE address in SMRAM• SMI handler overwrites saved SMBASE on exploit’s behalf with address of fake
SMBASE (e.g. 0 PA)
RAX (code)
RBX (pointer)
RCX (function)
SMI
SMBASE
Fake SMI handler
Saved SMBASE value SMM State Save Area
SMI Entry Point (SMBASE + 8000h)
![Page 68: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/68.jpg)
How does the attack work?Phys Memory
SMI Handler
OS Memory
• Attacker triggers another SMI• CPU executes fake SMI handler at new entry point outside of original protected
SMRAM because SMBASE location changed
SMI
SMBASE
Fake SMI handler
Saved SMBASE value SMM State Save Area
New SMI Entry Point
![Page 69: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/69.jpg)
How does the attack work?
• Fake SMI handler disables original SMRAM protection (disables SMRR)• Then restores original SMBASE value to switch back to original SMRAM
Phys Memory
SMI Handler(SMRAM is not protected)
OS Memory
SMBASE
Fake SMI handler
SMM State Save Area
New SMI Entry Point
SMI Handler(SMRAM is not protected)
Original saved SMBASE value
![Page 70: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/70.jpg)
How does the attack work?Phys Memory
SMI Handler(SMRAM is not protected)
OS Memory
• The SMRAM is restored but not protected by HW anymore• The SMI handler may be modified by attacker as well as other SMRAM data
SMBASE
SMI Entry Point (SMBASE + 8000h)
![Page 71: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/71.jpg)
Demo
![Page 72: Memory Corruption: from sandbox to SMM](https://reader035.fdocuments.us/reader035/viewer/2022062320/55b35146bb61eb43148b4733/html5/thumbnails/72.jpg)
Q&A
• Thank you!