Breaking Bad BIOS: Attacking and Defending BIOS in 2015
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 9 | |
| Number of Parts | 18 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32810 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
REcon 20159 / 18
1
2
3
4
10
12
14
15
18
00:00
Level (video gaming)Right angleBranch (computer science)Information securityAdditionImplementationProduct (business)Pointer (computer programming)Vulnerability (computing)Instance (computer science)Configuration spacePresentation of a groupVariable (mathematics)1 (number)Moment (mathematics)SpacetimeObservational studySocial classAmenable groupDisk read-and-write headMultiplicationBuffer solutionDataflowState of matterHand fanCodeStudent's t-testLattice (group)BuildingBitFamilyContext awarenessFirmwareScripting languageAreaoutputSoftware bugBootingExploit (computer security)Computer animation
05:16
Focus (optics)Term (mathematics)Vulnerability (computing)Physical systemSocial class2 (number)FirmwarePointer (computer programming)Asynchronous Transfer ModeoutputVariable (mathematics)Polar coordinate systemBootingNumberFlash memoryCondition numberComputer configurationType theoryInformation securityProduct (business)Electronic signatureInstance (computer science)MultilaterationFormal verificationTwitterBitWritingPoint (geometry)Service (economics)ImplementationOpen sourceAttribute grammarRun time (program lifecycle phase)CodeMiniDiscBootingMultiplicationEncryptionScripting languageContent (media)State of matterProjective planeFiber (mathematics)Right angleMaxima and minimaTrailProcess (computing)EstimatorLatent heatComputer animation
10:33
Goodness of fitTable (information)Vulnerability (computing)Data structureBitMultiplicationNatural numberHacker (term)Presentation of a groupScripting languageWordNon-volatile memoryCryptographyPointer (computer programming)Fiber (mathematics)Type theoryPhysical systemLengthCore dumpGenderBootingHexagonFirmwareVariable (mathematics)Flash memorySet (mathematics)
12:45
Scripting languageBootingCore dumpCodeIntegrated development environmentMultiplicationService (economics)Device driverBinary codeLevel (video gaming)Physical systemNon-volatile memoryLatent heatInformation securityFirmwareState of matterTable (information)Connectivity (graph theory)Heat transferCoprocessorBitConfiguration spaceEvent horizonSoftwareProduct (business)Multiplication signKernel (computing)Row (database)Process capability indexComputer hardwareBoss CorporationWritingInformationType theoryReading (process)Position operatorAddress spaceBridging (networking)Game controllerProcess (computing)Slide ruleComputing platformIdentity managementPoint (geometry)Linear codeFlash memoryDifferent (Kate Ryan album)PhysicalismWebsiteRight angleOpcodeWeightFrequencyRange (statistics)ProteinSheaf (mathematics)Inverse elementMetropolitan area networkOvalAdditionTouchscreenSerial portMassPresentation of a groupProof theoryWorkstation <Musikinstrument>Object (grammar)Computer animationXML
19:46
Right anglePhysical systemOctavePointer (computer programming)Table (information)Scripting languageNon-volatile memoryImplementationLogical constantVariable (mathematics)Cartesian coordinate systemVector spaceReduction of orderPoint (geometry)Group actionInstallation artMeasurementProxy serverInformation securityContext awarenessAttribute grammarRun time (program lifecycle phase)CodeAsynchronous Transfer ModeAddress spaceService (economics)CASE <Informatik>Computer hardwareConfiguration spaceLatent heatInformationComputer architectureContent (media)Data structureHydraulic jumpModule (mathematics)FunktionalanalysisFirmwareComputing platformKey (cryptography)BootingMalwareOpcodeRewritingLevel (video gaming)RootkitFlash memoryComputer animation
24:49
Game controllerBootingFirmwareFlash memorySoftware testingVulnerability (computing)Suite (music)Demo (music)Physical systemRing (mathematics)Computer animation
25:44
Non-volatile memoryOpcodeCodeRight angleBootingScripting languageState of matterWritingSoftware testingTask (computing)Wave packetDemo (music)Physical systemVideoconferencingSource codeComputer animation
27:14
Physical systemFirmwareDemo (music)Latent heatService (economics)SoftwareRow (database)Scripting languageState of matterBootingComputer animationSource code
28:10
State of matterOpcodeCodeScripting languageBootingNon-volatile memoryDialectBitSource codeComputer animation
29:33
Physical systemBootingBitWritingData storage deviceRight angleDemo (music)Data managementMultiplication signPower (physics)Scripting languageComputer animationSource code
30:59
CodeScripting languageBootingGame controllerRight angleSource codeComputer animationJSON
31:54
FlagNon-volatile memoryMechanism designImplementationData storage deviceVariable (mathematics)Table (information)FirmwareSet (mathematics)Open sourceBootingScripting languageEncryptionMalwareRegular graphDynamic random-access memoryWindowLink (knot theory)VarianceRun time (program lifecycle phase)MereologyPhysical systemCore dumpPointer (computer programming)CodeVulnerability (computing)Ocean currentBranch (computer science)Computing platformAddress spaceData structureSlide ruleWave packetPoint (geometry)CuboidBootingData managementSpeicherschutzIntegrated development environmentNumberService (economics)Device driverSocial classConfiguration spacePrisoner's dilemmaModule (mathematics)Key (cryptography)Uniqueness quantificationGoodness of fitPersonal digital assistantMetropolitan area networkWordFlash memoryComputer animation
37:17
Vulnerability (computing)BootingTouchscreenData storage devicePhysical systemOrder (biology)Configuration spaceComputer hardwareVariable (mathematics)Information securityPresentation of a groupAsynchronous Transfer ModeBuffer solutionCodeAddress spaceData structureRootMultilaterationContent (media)Computing platformSet (mathematics)FirmwareProxy serverDefault (computer science)Demo (music)Service (economics)State diagramPointer (computer programming)WindowInterface (computing)WritingFlash memoryPasswordRun time (program lifecycle phase)Open sourcePhysicalismMalwareDifferent (Kate Ryan album)ImplementationInstance (computer science)ResultantAttribute grammarFunction (mathematics)Key (cryptography)TheoryVoltmeterRevision controlBitRight angleNumberINTEGRALAdditionWater vaporPublic key certificateGoodness of fitCongruence subgroupLogical constantNon-volatile memoryBootingDataflowView (database)Translation memoryComputer animation
42:41
Configuration spaceInformation securityVariable (mathematics)Content (media)Product (business)Set (mathematics)Validity (statistics)Phase transitionAsynchronous Transfer ModeCartesian coordinate systemFirmwareRead-only memoryAuthenticationCommunications protocolImplementationMechanism designPhysical systemAddress spaceBootingType theoryRange (statistics)BitWeb pageNon-volatile memoryGame controllerAuditory maskingPasswordSensitivity analysisINTEGRALSoftware testingFerry CorstenSoftware protection donglePoint (geometry)Pointer (computer programming)Connectivity (graph theory)Level (video gaming)Parameter (computer programming)Open sourceDefault (computer science)CatastrophismData recoveryAreaBefehlsprozessorContext awarenessSocial classState of matteroutputCodeData storage deviceDifferent (Kate Ryan album)Computer configurationRun time (program lifecycle phase)Touch typingSpeicherschutzLimit (category theory)Presentation of a groupFlow separationReguläres MaßComputer hardwareControl flowBridging (networking)TheoryReplication (computing)Logical constantCubeParticle systemLatent heatFreewareBlock (periodic table)WeightRight angleMassBranch (computer science)Natural numberBootingService (economics)Goodness of fitWordXMLUMLComputer animation
50:32
SeitentabelleCodeScripting languageDataflowPoint (geometry)Device driverUniform resource locatorPhysicalismNon-volatile memoryLeakWeb pageFunktionalanalysisAddress spaceValidity (statistics)Partition (number theory)Software bugKernel (computing)SpacetimePointer (computer programming)MalwareTime zoneContext awarenessReverse engineeringCartesian coordinate systemVulnerability (computing)Auditory maskingBitDefault (computer science)Different (Kate Ryan album)Demo (music)State of matterMaxima and minimaBefehlsprozessorField (computer science)HexagonRing (mathematics)Ferry CorstenRange (statistics)Descriptive statisticsGame controllerArithmetic meanFunction (mathematics)Parameter (computer programming)Data structureComputer configurationCASE <Informatik>Poynting vectorBasis <Mathematik>NumberPhysical systemDebuggerMetropolitan area networkVapor barrierPower (physics)AuthorizationTerm (mathematics)EstimatorLatent heatTwitterLevel (video gaming)Similarity (geometry)Dimensional analysisTotal S.A.SummierbarkeitFlagInsertion lossTable (information)Statement (computer science)Execution unitMathematical analysisCuboidMathematicsPredicate (grammar)Set (mathematics)Core dumpDigital electronicsComputer animation
58:17
Context awarenessPerfect groupChainNon-volatile memoryMultiplication signSlide ruleExpert systemGodDefault (computer science)Range (statistics)Asynchronous Transfer ModeRegular graphVideoconferencingAddress spaceSource codeComputer animation
59:57
Pointer (computer programming)Operating systemGreatest elementAddress spaceSocial classTable (information)Type theoryValidity (statistics)Game controllerStress (mechanics)FirmwareCondition numberSoftware bugParameter (computer programming)Buffer solutionConfiguration spaceField (computer science)WindowComputer fileFunktionalanalysisVariable (mathematics)Non-volatile memoryLine (geometry)Point (geometry)Figurate numberSummierbarkeitMereologyMedical imagingCASE <Informatik>ComputerQuantumEmailLatent heatSystem callDoubling the cubeEndliche ModelltheoriePhysical systemSource codeComputer animation
01:04:03
VideoconferencingDemo (music)Multiplication signSocial classSystem callMetropolitan area networkClosed setVulnerability (computing)Source codeJSONComputer animation
01:05:06
Software frameworkOpen sourceInformation securityVulnerability (computing)Translation (relic)Multiplication signProduct (business)WordInternet forumDemosceneSlide ruleInformationSoftware testingNon-volatile memoryPhysical systemScripting languageRight angleEnterprise architectureExploit (computer security)Context awarenessSound effectSocial classLatent heatSoftware developerFirmwarePointer (computer programming)Computer hardwareComputer animation
Transcript: English(auto-generated)
00:16
Hey everyone. Microphone check.
00:21
My name is Yuri. This is Alex. We're from ATR team at Intel Security, working on the firmware over the last couple of years. The presentation today is Breaking Bad Bios or Attacking and Defending Bios in 2015.
00:46
First couple of things. Thank you for coming over here. I know 10 o'clock is pretty early after party night, so thank you. Thanks Sam, Hugo, and the rest of the recon team for inviting us.
01:01
And especially thank you to Sergey Brados and Anja for actually listening us talk yesterday during the party. So that takes a lot of courage to switch the party to listening today. All right. So we are actually talking heads here today.
01:21
And this is the work of the entire team. And a lot of vulnerabilities were found by the rest of the guys. A lot of vulnerabilities coordinated by the rest of the guys and exploits developed for them. So let's start. Today's agenda is we'll primarily focus on the major classes, several, not all of them,
01:42
but the major classes of vulnerabilities in the U5 firmware and the BIOS discovered in the recent two years. So we will not talk about everything as we usually like to do. But we'll talk about everything and work almost everything in the past few years. We will also discuss the overall state of the firmware security in the recent two years,
02:05
including how those vulnerabilities can be detected, some of them can be, and including how those vulnerabilities are being mitigated by the industry. So for those of you who are fans of Soviet sci-fi or post-Soviet sci-fi,
02:28
most of the quotes here are either from or based on books or novels from Strugatsky brothers. The last brother, Boris, he died three years ago or two years ago.
02:44
So I'm a fan of them. So as a start, we seem to have a little bit of a problem in this area with 37 unique vulnerabilities publicly disclosed in the last few years by only a handful of researchers looking at that space.
03:02
And 37, as you can imagine, those are the ones that were known at the moment. And we don't know what we don't know. We don't know how many vulnerabilities are being exploited in the world actively, how many vulnerabilities are found by nation states or some other actors. So in fact, multiple of those 37 vulnerabilities are classes of issues.
03:24
They're not a single bug. They're not one buffer of flow. They're a class of multiple issues with many instances present in multiple firmware products. For example, SMI input pointers, SMI callouts,
03:45
or indiscriminate usage of UFI variables, which is a configuration for a UFI-based firmware. Many same issues affecting multiple firmware products at once. For example, you might have heard about the S3 boot script issues, the UFI variables, again, issues with the SMI handlers.
04:03
If there's one issue in one product, there are likely to be multiple of them or even many of them in the same product. And I'm looking at the back of the stage because I once almost fell off the stage during talking. And even the basic things like missing write protection on the BIOS firmware.
04:25
So, in addition, there's a reference code branch for the UFI firmware, EDK2 branch. The issues in the EDK2 branch are being discovered, and they might have found their way into the final products
04:40
who might be taking code from the reference implementation. Or they may find their way into the future products as well. And as all of us know, updating firmware is not really a trivial thing to do. So, these are the issues. These are issues primarily discovered in 2013, 2014.
05:02
We started looking at the vulnerabilities basically in the context of bypassing something, some security technologies that are building on top of UFI firmware or the BIOS like full disk encryption systems with TPM or secure booting of the OS.
05:23
So we found a multiple of those that would allow bypassing secure boot, for example, jointly with other researchers from, let's say, Legba Core and others. Then there are a number of vulnerabilities were found associated with the UFI variables,
05:44
including first bypassing secure boot, then essentially making system unbootable or breaking the system through the UFI variables. Then a number of vulnerabilities were found in the capsule update for some of the specific systems.
06:05
A number of vulnerabilities affecting BIOS write protections, like, for example, the SMI suppression attack or the Speed Racer, which were found by Legba Core. Then at some point in 2014, we had a good look at the open source reference implementation
06:25
together with other researchers and found a number of vulnerabilities there, including things like capsule update vulnerabilities found by Legba Core. The issue with UFI variables where someone can bypass the boot services only protections of the UFI variables
06:49
and reinstall that variable with the runtime attributes. A number of issues related to the variables. A number of issues related to the SMI handlers, including race conditions and arbitrary SMI handler overwrite.
07:04
We'll talk about those a little bit later. Padding verification in the RSA, which is the base for the secure boot checks and other signature base checks. And 2014, 2015, so the trend continues that there are quite a few issues being found.
07:28
More and more researchers started looking at that. You can see that the discover column now has a little bit more names in it with issues being discovered not only on PCS systems, but also on Macs.
07:45
For example, the EFI option ROMs discovered by Trammel-Hatson and actually based on the earlier vulnerability discovered by Jim Fear. And the recent problem with flash being unlocked on Macs after the system resumes from sleep.
08:07
So the preliminary conclusion to that is your system is definitely maybe vulnerable to the bias vulnerabilities.
08:23
So how do we solve that problem? One way to solve that problem is like this. But we know where this ends, so maybe that is not the best way to solve this industry-wide problem.
08:41
That's why we will talk about some of the classes of those issues, which affect multiple products and typically have multiple instances in each product. We'll focus on four types of vulnerabilities. One of the recently discovered issues associated with the bias trying to, or when I say bias, it doesn't necessarily mean the bias in the legacy term.
09:04
It may mean the existing EFI-based firmware or UEFI-based firmware. So when the bias is resuming from sleep state, when you put the system to sleep and then resume, then there are vulnerabilities associated with that process. And the second class of issues is the attacks through UEFI variables,
09:24
which seems to be very prevalent on a lot of systems. Attacks via the so-called bad or poisonous SMI input pointers, which result into a code execution in the SMM mode. And the attacks via the SMI callouts, which also result into code execution in SMM.
09:48
I named all of those vulnerabilities for those of you who like names. S3 sleep resume boot script, bad bias variable contents, SMI handler bad input pointers.
10:01
You can see hashtags. Or the last one is this voluntarily had to be gone long ago. So let's start. How many of you have sleep problems? Well, a few. Well, many more of you have sleep problems, I believe. So let's talk about those sleep problems.
10:21
Attacking via the S3 resume boot script, which is sleep resume boot script. All the issues in that class happen during system waking up from sleep. So there's a TV for those issues. Kind of the whole type of issues.
10:42
First, those Freddy Krueger vulnerabilities were independently discovered by us and researchers. Other researchers, Rafal Wojciech from Abramium and Legg-Bacor researchers. So Rafal and Corey talked about those issues last December.
11:02
And they have a white paper and a presentation on that. The POC exploit was developed and described at length by Metro Lexyuk in this reference. And also recently Pedro Vilaca found related vulnerability in Mac EFI firmware.
11:30
Where flash lock is getting lost upon reserving from sleep. So what are those problems?
11:42
I'll explain a little bit more details about what resume boot script is. But first how to find it. The resume boot script can be found on some systems, especially on vulnerable systems. In a UFI variable called ACBI global variable. It points to a structure in memory which contains another set of pointers.
12:03
Pointers to other structures that the UFI based firmware typically uses when it resumes from sleep. And one of those pointers is the pointer to the boot script itself. So you can see that pointer is exactly where the S3 resume boot script table is in memory.
12:23
So that is a kind of structure defining all of those pointers in memory. Including you can see that ACBI boot script table pointer is an offset 18 hex in that structure. This structure is somewhere in memory and on vulnerable systems in unprotected memory.
12:46
So this is a, you can see the dump of the boot script containing the up codes. So what is boot script exactly?
13:01
Why is it called script? When EFI firmware normally boots, it executes sec security stage, pre-EFI initialization stage. Then followed by Dixie stage driver execution environment. Where the bulk of code runs.
13:20
Multiple binary PE coffee executables are running during Dixie stage. Those are called drivers for different devices. Sometimes just service drivers without specific device. A lot of code. And that code initializes the system or continues initialization of the system. After memory is available, after pre-EFI initialization stage.
13:43
So when you put system to sleep, you don't really want to wait all of that time when you wake up from sleep. You don't want all this code getting executed. And so the AI based firmware solved that problem by introducing this concept of a script.
14:03
Where on a normal boot, each driver, firmware driver. When I say driver, it means firmware driver, not kernel drive driver. So each firmware driver records the configuration it makes to a hardware into a script like table.
14:22
Creating multiple up codes. This script will get executed by firmware upon wake up from sleep state. Without actually running all of those drivers. Without executing all of that code.
14:40
So only PEI stage, and security stage of course, is executed on resuming from sleep. Then just the initial early component of the DXA stage, DXA is loaded. Which transfers execution to S3 related component.
15:00
Which knows how to interpret the boot script. Execute all of the up codes from that boot script. And this process restores full configuration as it was done on a normal boot prior to sleep. Without actually going through all of that code. So those are up codes from the screenshot a couple of slides ago.
15:29
There's a position of the up code within the script. There's an up code value. Depending on which up code it is, there's an address of the register. There's a value that is being written to that register.
15:43
So this is how those up codes look like. The first one you can see, it's actually the very first up code in the boot script. It's a memory write. It's a memory write to an address FEC 5 0's with a value 0. It's actually not a memory write, it's an MMIO write.
16:02
It's writing to an MMIO register. Memory mapped to you. The second up code, which is not really the second up code, it's a 3 59th up code in the script. Is a IO read write. It's actually writing some value 21 to a register 430, which is a register somewhere in the PM base.
16:28
But it's not just writing, it's actually reading, modifying writing. That's why it's a read write up code. And that's why there's a mask. You can see how many up codes are in the script. There are more than a thousand of those on typical system.
16:42
This up code has position 3 59. So what other up codes are present in the boot script? IO port write or read write. Memory write or read write. PCI configuration registers write or read write. SM boss executes, so you can execute a specific instruction on SM boss from the boot script.
17:01
It's tall when you can wait for some amount of time. The firmware will wait. The dispatch up codes, those are interesting up codes. They execute arbitrary code. Very useful up codes for attackers. Information up codes, there are more up codes like stall up codes that wait for a certain value to appear in a certain register.
17:25
A little bit more details. This is an example of IO port up code. This up code writes to a specific processor IO port. And the port here is the, you can see, address. It's port B2. For those of you who work on PC firmware stuff, you know that this port is the APMC port that is used to trigger a software SMI event.
17:52
And this up code is writing value BD to this port. So it's sending an SMI. Now, the other up code is dispatch up code.
18:01
There are two types of dispatch up codes. In fact, some of the firmware products may have their platform specific up codes or firmware specific up codes, dispatch up codes. So this dispatch up codes basically executes a code at these entry points. You can see the address. It's a physical, it's a linear address, but it's identical mapping, so it's a physical address in the firmware.
18:26
So it executes certain code early enough while interpreting the boot script. Now, this up code is PCI configuration write up code. It writes to a PCI configuration space, to a PCI configuration register of some device.
18:44
And this specific up code, 569, it is writing value, you can see value, to a one byte, to a register with an address 1F00DC. That's a offset DC in device 31.
19:04
Device 31 is an LPC bridge in the chipset, and this DC offset is called bias control register. Bias control register is responsible for some of the write protections of the bias firmware in the SPI flash in the non-volatile memory.
19:21
So writing some specific value to that bias control register either enables properly all those protections of the bias firmware in SPI flash memory or disables them. So this specific value to a, it's correctly enabling all of the write protections of the bias firmware in the SPI flash.
19:42
A different value if it's written, then it may disable protections. So, what can go wrong with this architecture? First, the address to the actual boot script or the structure which has a pointer to the boot script is maybe stored in a run time accessible place.
20:08
In a place accessible to the OS and therefore OS level malware. For example, if you consider this ACPI global table variable, if it has attributes, non-volatile, RT, run time, BS, not that BS, but boot services only.
20:26
So, in that case, this variable is accessible from, to anyone executing with the OS privileges. And in fact, even more, because OSes provide API to the user mode to talk to the variables, to write variables. So, in fact, this is accessible to the user mode applications on most of the OSes.
20:45
So, if that address to a boot script table is stored in such a variable, then anybody can modify it and point to a different completely bogus boot script. And when system resumes from S3, the firmware will execute completely bogus boot script.
21:03
Or the boot script itself may be stored in a memory accessible to the OS and the malware in the OS. So, that malware could just modify that boot script table before putting system to sleep and after system will resume, wake up from sleep.
21:22
That modified boot script will get executed. Now, remember that there's an actual code interpreting that boot script and executing the opcodes. Some implementations don't want to boot even that code. So, what they do is they actually stash it to memory, put the system to sleep.
21:42
And remember that in sleep, memory, contents of the memory is preserved because the RAM is in self-refresh. So, all of the contents are left in memory. And when the system resumes from S3, the firmware finds that module, the boot script executor, and jumps to it. And this boot script executor already in its turn finding the actual table, boot script table, and interpreting the boot script table.
22:06
So, if that module, that executable, is stored in unprotected memory, then you don't need to modify the boot script. You just need to modify the code that is executing the boot script. Now, assume that both the code and the boot script table are protected somehow.
22:24
If you remember those dispatch of codes that jump to a arbitrary code, arbitrary function to do some extra initialization of the platform. Those dispatch of codes, they have addresses of the entry points. So, even if the boot script is protected, the dispatch of code points to some code.
22:43
And if that code at that entry point is stored in a less accessible memory, then that code can get modified by the molar and will get executed. And finally, certain systems or some systems may just forget on a normal boot when that firmware executes on that system.
23:07
On a normal boot, they configure the hardware with, let's say, and enable bias protections. But they forget to store or save that information in the boot script.
23:21
And if they do that, if they forget to do that, then upon resuming from sleep, that configuration will not get restored. So, if on a normal boot you had some protection, like bias is write protected, then you put the system to sleep, wake up, and that protection is gone. And that happens because firmware may happen because firmware just forgot to put the specific opcode restoring that protection.
23:49
So, what's the impact? Malware in the OS is able to change the actions that are performed by firmware on S3 resume before OS resumes at the waking vector.
24:01
So, what? Okay. Explaining further, malware can execute our boot script firmware code during earlier resume, way before the OS. Malware can disable hardware protection, such as bias write protection, which are going to be restored by the script. Malware can install persistent bias rootkit in the spy flash memory because the protections are not there yet.
24:26
Or it can rewrite arbitrary memory or execute arbitrary code, which I already said, for some reason, in the context of system firmware early enough in the PEI stage. Or bypass OS security measures like secure boot, for example.
24:43
Pretty bad impact, right? For those of you who are far from firmware, yes, it can also steal your PGP keys. So, the nice quote that suits this vulnerability is that 93% of the days in the year started the same.
25:08
The alarm clock rings, and then your vulnerable bias boots or awakes from sleep. Let's go through a demo. I'll explain a couple slides on the demo, and then I'll just show that on a system.
25:26
So, imagine that you had bias protected in spy flash memory. So, we're running our chipset test that is testing the write protection of the firmware. And it says that, hey, bias is write protected, everything is good. You can see that the bias control register has value 2A, which I previously mentioned.
25:44
So, basically, you can sleep well. Go ahead and sleep well, but before you go to sleep, an exploit executes approximately this code. So, it finds the boot script unprotected in memory, then modifies, and it finds the opcode that restores bias protection with the value 2A.
26:04
So, that opcode is restoring bias protection in a state on, and changing it to restore bias write protection in the state off. After you wake from sleep, the same test that is checking bias write protection says that it's not completely protected.
26:24
When it says that, it's pretty much not protected at all. So, let's do the trick. I wanted to record a demo because videos fail much rarer than the actual demo.
26:44
But because we had a very intense training, I actually couldn't do that. So, if you think that you'll do something during the training, other than the training itself, you're mistaken. You probably won't do anything.
27:02
So, let's just do the live demo. So, let me check protections on this system.
27:25
And I know, unfortunately, that this system is not protecting the bias firmware on the SpyFlash. I'm using it for a demo specifically. So, I'll actually, I'll do it a service. I'll enable the write protection.
27:43
Okay, so now I, or no one from the software should be able to write to the SpyFlash, which I won't do. I don't want to break the system I project from. So, now you can see that the write protections are, you can see passed somewhere here. Bias is write protected, so we're fine.
28:07
Now, I'll find a boot script that will get interpreted and executed upon resume from S3, from sleep state. And you can see that we've parsed the boot script.
28:24
There are opcodes here. I'll find the opcode that is responsible for restoring bias write protection. You can see that this is the opcode. It is restoring a bad value. It is restoring, originally it is restoring a value that is really not enabling bias protection.
28:45
So, but I'll restore a different value. Anyway, so now before going to sleep, I'll actually run a tool that will modify that boot script in memory.
29:05
It will find an opcode. I'm hoping so, yeah. It found an opcode in the boot script that is responsible for restoring. You can see a regional value 8, a regional value 8, and modified value 9.
29:28
So, both of them are bad. I'm just replacing it with a worse, a little bit worse value. Oh, yeah, so now I'm just closing this thing, hoping that it will come back again.
29:56
Okay, it's up here. It should be there soon.
30:05
Yeah, it's up. You can see that it happens a little bit faster than usual. Yeah, you wouldn't boot the system that fast. That's why it came up from sleep. Now, the only thing I will do right now is I will check the bias write protection. And you remember that before putting it to sleep, it was on.
30:22
Now you can see that it's failed. Bias is not protected. So, the only thing I did is I closed the lid, opened it back again, and bias protection was gone. I did that just for demo purposes. In fact, you don't really need to ask a user to close the lid and open it back. You just put the system to sleep by OS means or just directly writing to bar management registers in the chipset.
30:45
And it will wake in an amount of time that you told it to wake. Now, let me dump the boot script again and find the same up code.
31:05
And you can see that this up code in the boot script has value nine instead of eight as before. So, that up code got executed. And this is the value you actually see in the bias control register right here.
31:34
It's value nine. Okay, so protections are completely gone because we've been able to exploit the S3 boot script.
31:41
And this is just basically showing that the boot scripts after resume from sleep, this has this value which is not properly restoring bias protection. So, how do we detect and mitigate those issues? First of all, there is a script in chipset currently.
32:01
It's not in the open source. Of course, it's going to be in open source branch of chipset pretty soon after recon. So, that module you can run it on any system. You can test whether the firmware is properly protecting, has mitigations against those S3 boot script vulnerabilities.
32:28
So, how do we fix those problems? Well, those are pretty common sense recommendations to whoever develops the bias firmware or the platform manufacturers. Do not keep address of the boot script to the boot script or a structure with a pointer to the boot script in unprotected variables.
32:46
Do not save the boot script table itself to the unprotected memory or memory that is accessible to the DMA devices. There is a mechanism in the reference code implementation for ADK2 that is called log box that can help with protecting the boot script.
33:03
Do not save the actual executable that is interpreting the boot script in unprotected memory. And I'm saying that again in number four. Do not save the pointer to the boot script in the EFI variable. Well, I must have modified those slides in between training sessions.
33:24
And of course, review the actual dispatch up codes or the entry points to those dispatch up codes such that they do not point to a code. They do not jump to a code which is an unprotected memory. So, one of the ways to protect the stuff in ADK2 based firmware, in EFI based firmware is a so called log box.
33:45
So, on the left you can see a boot script plus some management structure pointing to that boot script. On a vulnerable system that is red, that is outside of protected memory. In fact, you can use log box as a generic mechanism.
34:03
You can protect arbitrary data using arbitrary mechanism. You can use read only variables. You can use some encrypted storage or something like that. But this one, this example specifically shows using SMRAM to protect boot script. So, remember that SMRAM is not accessible to regular malware minus vulnerabilities in the SMI handlers, of course.
34:26
So, basically the EFI based firmware systems, they may place that boot script and the executable that will be interpreting the boot script into a protected SMRAM memory. And executed upon resume off the SMRAM without going out into the DRAM.
34:44
So, there is a link to a actual open source implementation of this mechanism in ADK2. Here is one example how the reference implementation saves the actual boot script to the SMRAM. And then it sets a flag that says that, hey, upon resume execute
35:02
that in place without copying it back to DRAM, without executing from unprotected memory. With that, let me jump to another class of issues. Issues related to UEFI variables. UEFI variables is the main mechanism to store configuration, including non-persistent configuration for a UEFI based firmware.
35:28
So, what does firmware actually stores, which settings it's storing? First of all, it uses those, the variables, UEFI variables. Some of those variables are non-volatile.
35:41
They're actually being stored together with a BIOS with firmware on this bi-flash memory on non-volatile RAM. Variables can be boot services only accessible or runtime accessible. But accessible variables are accessible only to the firmware or the firmware drivers before the OS. Typically, somewhere at the end of the boot loader, those variables stop being accessible to the software.
36:06
Or the runtime accessible variables, those are accessible to pretty much any code in the OS, starting from reboot and until the next reboot.
36:21
The typical way in modern UEFI based systems to access those variables are through the SMI handlers at runtime. And also, the interesting fact is that most OSes, they do expose API to modify those variables. But not all, but only runtime variables. So, for example, you can see that the set firmware environment variable on Windows or the EFI VARs, VARs devices on Linux systems.
36:50
Now, firmware actually stores a lot of settings. This is the dump of parts of those settings in the UEFI variables stored in some system.
37:06
It was done using Chipsec as well. So you can see a whole bunch of those variables and settings stored in those variables. One example is a CPI global variable that we saw already storing pointer to the boot script table. Another variable is a boot order.
37:21
It's the variable that you use when you choose the boot order where to boot from in the BIOS setup screen. That's the variable that actually stores that boot order. The secure boot certificates, the root certificate, platform key, other certificates, whitelist, DB, blacklist, DBX. Those are also variables that are stored in variables.
37:43
Or the setup variable, which we'll talk a little bit later. So the setup variable is the variable that is storing all the settings you choose in the BIOS setup screen or the UEFI setup screen when you boot the system. Now, what we have found are the things we've found stored in the variables.
38:05
Unprotected variables read user mode accessible variables. Secure boot configuration. We've talked about that in one of the presentations we gave at cancer quest last year. The addresses to structures or buffers in memory, which firmware, when it boots, reads from or writes to.
38:26
The policies for hardware configuration or protections, including hardware log bits, such as the BIOS write protection policy or flash lock or BIOS interface lock. The policies disabling or enabling security features, depending on what you like more.
38:43
Or the data, which firmware really, really needs to just boot. There is data stored in non-persistent configuration that just is needed to boot the system. Or the secrets, sometimes even BIOS passwords. Who cares about them anymore, but BIOS passwords are sometimes stored in clear in those variables.
39:04
This obviously cannot be good. So overwrite early firmware code data if there is an address stored in the variable. If there is an address stored in the variable and the firmware reads it and then writes to that address, then any one user mode can modify that address to point to the firmware code or data itself.
39:24
And so the firmware upon early boot will write to that address, overwriting its own code or data. Or bypass UFI secure boot OS, secure boot configuration is critical settings, or even keys stored in those unprotected variables.
39:40
Or bypass or disable hardware protections, like BIOS write protection, if the policy for that BIOS write protection is stored in the variable. Or just make system unbootable, or break the system, if the data is stored in the variable that is required for system to boot and malware just corrupts it.
40:02
But that was a theory. In practice, there were found multiple unique vulnerabilities, approximately 50 different instances of vulnerabilities in different systems and in reference implementation related to UFI variables, only recently. Both the open source reference code, as well as actual implementation,
40:22
CFI-based implementation, suffer from those issues, which results in UFI secure boot bypass, unbootable platform, because of the corrupted contents of the variable, buffer flows when consuming the variable contents, arbitrary overrides because of the pointer stored in the variable, bypassing boot services protection by reinstalling the same variable
40:43
with lesser protection attributes with the runtime attributes, or bypassing physical presence, user presence, of some of the variables. So, one example of such vulnerabilities were discovered by Legba Core and us, as related to setup variable.
41:02
And it has a VU number, you can look it up later. So who needs setup anyway? Already we've showed that setup, some systems stored secure boot configuration in the setup variable, and that allowed us to bypass secure boot on those systems.
41:22
Now, user mode malware can access that setup variable and can just put, you know, write garbage in it, or just delete it. In addition, if there is a default contents that is being restored by the firmware when setup is not available, some systems may store that default
41:42
also in the unprotected variable, for example, std default, so the attacker may delete it or corrupt it as well. So when this happens, then the system may never boot again, because it really needs those settings, and they're being corrupted.
42:02
I won't be making this demo on this laptop. But, you know, why bother about this? Just bring it to the IT service desk and ask to reinstall your firmware on the laptop, like we normally do, right? My Outlook doesn't open, or my Windows doesn't boot, so my system doesn't boot.
42:20
Can you reinstall the firmware? So that's probably the reaction you'll get from the IT service, right? So you might have just bring this thing to them to get the same reaction. It's not easy to do. So how do we avoid problems associated with the variables?
42:41
Again, well, first, keep calm and secure them. It's not rocket science to secure configuration. There are certain just common sense recommendations how the firmware has to handle those variables. First of all, limit the access to the variables. Separate critical settings from non-critical, from other settings.
43:01
Store them in different variables, in different places with different protections. That's easy. If you have setup options that you really care about, store them not in the setup variable, but in the setup something private that has right protections to that, and the rest of the setups and the settings store in the regular setup accessible to the runtime.
43:24
Remove runtime access whenever not needed. So some variables do not really need to be modifiable by the OS or even readable by the OS. If you dump the variables, for example, using chipset, you'll see a whole bunch of them, almost a hundred of them on your system from the OS.
43:42
Ninety-nine percent of those variables are not needed to the OS. The OS doesn't touch it, none of the applications touch it. Why they have runtime attributes, they shouldn't have. They're only needed for the firmware. Make some variables read-only. If OS needs to read them or applications needs to read them but not modify them, make them read-only. There's a variable lock protocol in ADK2 reference implementation that firmware can use.
44:06
Authenticate variables. There's a whole mechanism defined by the UEFI spec to authenticate variables. Remove debug test content. For example, policies to disable hardware locks that are really useful during the validation pre-production phase but really shouldn't be there in the production systems.
44:23
Use PCD settings for some variables. Those are kind of settings that can configure your bias during the build, not runtime. Some variables do require physically present user. For example, setup mode in the secure boot implementation. It needs to be only modifiable when user types something or presses a button.
44:44
Or the firmware implementations may actually implement some integrity checks, as we've seen on some systems on the critical settings. And of course, the storing bias passwords is probably not the unclear or any other sensitive contents like Wi-Fi passwords or something like that is not a really good protection in the variables.
45:05
So the other class of common sense recommendation is validate contents of those variables. Assume that the contents of the variables is malicious or are malicious. Validate them before consuming by the firmware. Is there an address in the variable?
45:21
If there is an address, make sure that it's not pointing to your own code or data. Validate data written to the variables. Sometimes firmware knows the set of data, allowed settings that can be stored in the variable. So why not validate the actual value written to that variable through the API
45:44
that this value is within the predefined set of allowed values. Can you boot if this variable is corrupted? If you cannot, have a default in a place which is protected. And enter recovery if you notice that the variable contents is corrupted.
46:03
And of course, if everything fails, our firmware products need to have a catastrophic recovery mechanism. You press the jumper and something happens magically, like restoring all the defaults, including configuration. So one of the ways to protect the variables is read-only or variable lock protocol
46:24
defined by the implemented open source in the reference implementation. So the way it works is there is a variable lock protocol loaded during the DXA stage during the firmware which exposes API, this request to lock, that any firmware component may use, may invoke
46:47
to request that a specific variable will become read-only at some point. So at this point, all the variables are read-writable. But at some point, and that point is the end of Dixie, the end of a specific stage
47:00
where firmware almost hands off to the boot loaders. At that point, these variables that were requested to be read-only become read-only and not writable anymore, not createable, not deleteable. And exit boot services, for those of you who looked at the UFI exit boot services,
47:23
is the point of handing off to the actual OS. So this is where OS will start. And the OS at that point won't be able to write to those read-only variables. Okay, so that's all for this class of issues in the UFI-based firmware.
47:45
We're jumping to another, the third class, which we call poisonous pointers. We're attacking a semi-handler's firmware via invalidated input pointers. And we are biased toward bias, so where there's no bias for us, there's boredom.
48:04
And the bias actually makes life interesting for us. So with that, I'm switching to Alex to continue with explaining that type of issues. Hi, my name is Alex, and I will continue this presentation for this type of attack and the next one.
48:27
And before we start, I want to describe a little bit basics that we make sure that we're all on the same page. So what is SRAM is? This is protected memory where all SMM code lives, including SMM handlers.
48:45
And this protected range, the pointer to this protected range is live in SMBase MSR, which is accessible just in SMM.
49:02
And this range has protection from CPU, is range register protection, SMR mask and SMRBase. And also, it has DMA protection in the memory controller. If you look a little bit deeper inside the SMRAM, there is an area named CPU save state area,
49:26
which this area is used by the CPU to save and restore context of CPU registers, SMBase address. And there is also entry point to SMRAM name, SMI default handler, or SMI entry point, which live in SMBase plus 1000 hex.
49:54
And I will describe the bug, which is related to SMI implementation.
50:00
So the basic idea is that SMI handler get the input from the argument from IS. So OS pass the argument to the SMI handler through the general purpose registers. And as you can see here, from RX register, they pass the code for SMI.
50:24
The RBX, they pass the pointer. This pointer, in a legitimate way, should live in OS memory. And the RBX, they pass the function number. This is how the legitimate way this work.
50:40
Why they need actually this piece of memory inside the OS and point it to them? In a legitimate way, SMI somehow want to return the status of SMI. Is it fail or not? And this memory, they put the status to this memory, to their own partition system, knowing that this SMI is pass or fail.
51:03
And what if this pointer will be pointing back to SMM? What happen? And this is the old thing about this bug. So SMI handler doesn't validate the pointer. So it doesn't check that the pointer pointing outside of SMM,
51:21
meaning you can override something inside SMM. How you can exploit this? So what exactly you want to override? In many cases, you don't control the value which you override. You just can control the address.
51:40
So you just know where you want to override, but you don't know what you will override. You can pick different options of what exactly you want to override. For example, the default handler code, which I mentioned already, the entry point to SMM. So if you can override this, it can be exploitable.
52:02
You can override internal some structures flag, which related to SMI handlers. And also you can override CPU save state and the field inside the state. And there is one field which is really important, SMBase. So this value is pointing to SMRAM.
52:22
And the save to CPU save state when it comes to SMM, and they restore this value when exit from SMM happens from the resume instruction. So if you override this SMBase value, the next SMI which will come,
52:43
they will come in a new SMRAM and will start executing malicious code which will be not in protected ranges. I will describe that a little bit more later. But how do you know where SMBase is?
53:01
If you think about this, if you wrote exploit in ring 0 and ring 3, this is the problem really saying that ISLR in the kernel or user space application. So you don't know the context of SMRAM. You know the address which you can override, but you don't know where SMBase lives, where is exactly this stored.
53:24
What you can do? You can find, you can dump the old context of SMRAM from different ways. You can dump it from another vulnerability. As you already mentioned, a triple script. You can have this vulnerability to dump SMRAM.
53:41
You can use, and in this technique you will need to use graphic DMA. And I will describe a little bit later more details about this. Also you can dump all SpyFlash, extract all SMM Dixi drivers and reverse engineer them to find SMM initialization flow. And in that flow you can find the value of SMBase.
54:03
Also you can use another SMM point of vulnerabilities which is make a memory leak from SMM content. And the last one, if you have debug capabilities in JTAG Debugger, you can do this offline.
54:20
And just to make a dump. If you don't have, if you cannot find any way to dump the old entire SRAM, you exploit and try to guess various SMBases. And there is couple location which is more probable it can be.
54:42
So it can be a SMR physical base minus 8000 hex. Or it can be an SMR physical base address. Or you can try to, try to overwrite a couple times different pages inside SMM in a specific offset
55:04
to try to catch SMBase in experimental purpose. And after that use this value to exploit the vulnerability. Here is a little bit description about dumping the SMRAM through graphic.
55:24
So basically we assume that TCAC is not locked, that DMA can have access to the memory and the TCAC is below SMRAM. And in our specific exploit we use a three boost script to unlock the TCAC.
55:43
But there is many other options. After the, after the TCAC is below SMRAM, you can configure it graphic paging tables to look inside SMM and you use graphic aperture to get access to.
56:01
So basically all idea is use graphic DMA to get access to SMRAM. And after you have already the address of SMBase, you start thinking about how to exploit this. And in a legitimate way, how the SMI work as already described,
56:21
you send SMI and your argument is in general purpose registers and one of them is pointing to the OS memory. And, but you assume that you can override SMBase and there will be a different location of SMBase. In our case it will be zero because we override SMBase to zero.
56:41
But before you trigger this vulnerable SMI, you need to prepare the next default SMI handler because next SMI will use already new SMBase value. And in use of SMBase value, you need to prepare the old stage, minimum stage, to execute SMI entry point and all of this.
57:05
And in our specific case, we allocate the default handler in address 8000 hex. We allocate our shellcode, which we wanted to execute after we trigger second SMI. So now we trigger first vulnerable SMI, which is overwrite SMBase in a new value, which is zero.
57:28
This allow to next, SMI start to execute it from zero, 8000 hex address and here is already start executing your shellcode, your malicious code, in the context of SMM.
57:42
So code has SMM privileges, which is more privileges that are in zero. And you can do whatever you want. In our specific case, we disable range register protection, flipping the bits inside SMM mask MSR,
58:01
and we replace SMBase for default value. Then all SMM code can execute correctly for the old next SMIs. Here is a demo.
58:39
So we run the exploit one time.
58:42
So here, first we check that SMM is protected and we cannot read it. So the address is all Fs. Then we save the original new SMBase memory that we don't corrupt anything. Sorry, I didn't stop the video.
59:03
Then we prepare the new SMBase memory with new SMI default handler. And trigger first SMI to change the SMBase, and the next SMI we start to execute from our controlled memory, which is unprotected,
59:23
but with context in SMM, so with more privilege mode. And then we disable the regular SMM protection, range register protection, and then we check that now we can read and write the full SMM, the entire SMM.
59:44
And if we run this exploit again, this tells you this SMM already doesn't have protection and you can read and write it directly. So let's go back to the slides.
01:00:03
All this bug is related to the old UE5 base set system, which uses the argument for SMI pointers through the general purpose registers. In a new indicate to base set firmware, the firmware doesn't use the general purpose
01:00:28
register to pass the argument to the SMI handler. They use the special buffer to pass all arguments from operation system to SMI handlers.
01:00:43
This buffer named com-buffer, and the pointer to this com-buffer lives in a CPI table named UEFI. This particular example, which we can see, this com-buffer is sent the common buffer
01:01:03
to set variable, get variable, and the common buffer contains the header, the LAN, and the OS wants to pass this argument to SMI.
01:01:25
So they contain data, GUID, and the name of the UEFI variable. So the SMI handler gets this common buffer, and they know that inside this common buffer, depends on this function ID, this argument should be the UEFI variable, and they parse
01:01:47
all of these fields. What's the problem with this com-buffer? It's really similar to that in the previous class of attack. In this class of attack related to com-buffer, the SMI handler doesn't properly validate
01:02:08
common buffer, so you can manipulate from com-buffer to overwrite SMI. And here's an example. If you check the line in the bottom with copy mem, you can see the destination address
01:02:23
is pointer in the data. And if you follow this data, you figure out that this data is coming from com-buffer. And there is no protections, no checks, and any validations of this data is not pointing
01:02:40
to SMI. So if you attack a related control of the com-buffer, because the attacker controls the pointer in the CPI table and the memory, which is in that memory, and in this case, you can control the data and you can overwrite the SMI.
01:03:06
Okay, I will be fast. So another type of bug is really the same common buffer. There's a stress condition or a double fetch that's basically a window between checking and using the common buffer fields.
01:03:24
So you can modify, for example, from graphic DMA, this field after the check, but before they use it. So how we can detect and mitigate this kind of bug? There is chipset model, which can get the parameters configuration file with the config.
01:03:46
How you want to check? So in this specific example, you point that in SMI, 1F, you want the address to the memory will be in our base, and the OS registers will be random.
01:04:02
And here is the detection. It should be video here, or it should be live demo here, but I will continue. Video? Demo? Okay, demo.
01:04:20
Should I continue? No, just demo. Sam? How much time do we have? Zero? Oh, okay. I thought we had 90 minutes.
01:04:42
60? Oh, come on. Just so much interesting stuff here. All right. Well, we'll just have to close up, right? There's another class that we thought we would talk about. It's called one missed call, or how we call it, and this is really attacking SMI
01:05:02
handlers via the SMM callout vulnerabilities, right? So I'll just scroll through it. If you have a photographic memory, you should be able to see it. But I can tell you that mitigating that specific class of vulnerabilities is like trying to
01:05:21
fit an octopus into a pair of tuxedo pants. But it is possible. We can do it. So there is a slide of why we're actually investing in an open source framework tool that detects some of those vulnerabilities. There are multiple reasons to do that. So security researchers need a way to develop POCs, test exploitability, and impact of the issues.
01:05:43
And also they need to provide that information to the OEMs and bias vendors so that this industry can improve their products. And we also need security researchers to be able to capture that research in a consumable way, right? We also want corporate IT enterprises to be able to actually run it
01:06:06
and detect vulnerabilities on their systems that they are about to deploy on to their employees. And we believe that it's got to be an open source so that everyone can see what it's actually testing and which vulnerabilities it's actually testing. So conclusions.
01:06:21
The UFI bias firmware security is an industry-wide concern. Everyone is affected or may be affected. And there are often multiple issues of the same time, and some unfortunately take years to mitigate. But researchers keep finding dragons and drive awareness and also classes of vulnerabilities
01:06:41
like those SMI pointers or S3, which start disappearing, right? And many OEMs and bias vendors start to be responsive to the security issues, stepping up to improve security of their products, even use Chripsack, as we know. And even hardware protections are being slowly adopted.
01:07:02
So with that, let me just read it, because I don't remember the – I remember the Russian word saying, but not the translated one. I was told that this road would take me to the ocean at death and turn back halfway. Since then, crooks, roundabout, gut-forsaken paths stretch out before me.
01:07:21
So we'll have to continue that research. There are acknowledgements. I don't have time, but I do acknowledge all the people on this slide, including researchers and people who helped us at Intel and the UFI Forum members. And with that, we are leaving this scene.
01:07:41
Thank you.