Indeed. Check his Linkedin... Started working for Intel as senior security researcher in 2018... I bet they made him quite an offer. This guy was too dangerous to them to remain on the outside.
the way I interpreted it was that he made a brainfuck to MOV only asm compiler then decided to make a C to brainfuck or C to MOV only asm compiler. either way the optimization would be terrible unless that was all you had to work with.
We all are . What do you think keeps our heart going. If you believe in separation you get it just those who lost in the 1929 crash with a heart attack. Enjoy.. I will debate no further. To each his own journey.
I've worked my way back from more recent talks to here, and every single talk by this guy is awesome, he's just amazing. Half the time I'm just sitting here in disbelief with a stupid grin on my face.
that's not some stuff you learn in classes. but electronics engineering, processor architecture and embedded stuff may help you. and maybe some yoga and meditation to learn to handle the frustration of debugging stuff for hours and hours. and please, just keep in mind, that guy write a compiler which compiles C into a bunch of mov operation, or figured out a way to flip people the finger when they look at his code in IDA.
@@ko-Daegu exactly what I wrote. If you look at the assembly, compiled with that compiler, you only gonna see tons of mov instructions. Which makes it super annoying to reverse engineer.
27:35 validate the limit: `8026: test ax,ax; jz invalid_gdt`, validate the base: `802F: test eax,eax; jz invalid_gdt` - Can be mitigated with BIOS flash.
also unrelated I see that RUclips has bee messing around with their suggestion algorithm... most of the comments are no older then 2 days, most of them are less then 24h old, while the video is from 2016 (kinda) and originally only had three comments.
Brilliant find but since it requires Ring 0 access to implement the rootkit you need to work along other exploits to get to that level - or secret services modifying whole shipments prior of delivery.
i do miss this guy, hope hes done some amazing things while working at intel. rosenbridge was never released, I guess what he stumbled upon was so powerful and so close to getting the concept to work.
Watch more of his presentations and other Blackhat/Defcon/CCC(media.ccc.de on youtube) videos. also there is www.phrack.org/ :D so many cool things, stop watching and just do some hacking yourself ;) I cant staph watching hours of these
If Intel fixed the issue in Sandybridge, doesn't that imply that they were aware of the issue at some point prior to Sandybridge's release? Given the wide-reaching implications of this exploit (a Ring 0 breach elevating to Ring -2 potentially renders the system hardware itself untrustable from that point forwards), shouldn't Intel have immediately disclosed knowledge of this flaw so that security policies could be updated to account for the increased scope of vulnerability?
Maybe they did disclose it, but only to selected parties while they worked out a solution. If they didn't, maybe that was because it would make little sense making it public if at that time they were certain nobody else knew about it yet, or at least nobody about whom they need worry. Meanwhile, they work out a solution and plan a future arch fix. Reminds me a little of when Bletcheley Park discovered imminent attacks via broken Enigma messages (city bombings, sub attacks, etc.), but they could not act on the information because that would give away the fact that Enigma had been cracked (vaguely recall Coventry was one such target); people had to be allowed to die to keep the cracking of Enigma secret and thus useful. Sometimes it's better to stay quiet, and meanwhile work out very carefully who needs to know and when. I expect the first Intel would have told would be the NSA, etc. Good question to ask though! Obviously a very difficult area to define in terms of policy and actions/response. There are probably disclosure procedures in place that are not public; bit like there are parts of the UK's OSA which are secret. :D ie. I would be surprised if Intel did not have (already) relevant arrangements in place with security agencies, and then later the OEMs, etc., but if they do, it makes sense for any such procedures to not be in the public domain.
or really they should have kept it hush-hush so it wouldn't spread like wildfire to hackers who wanted to abuse it for bad, and only disclose it *after* it was "fixed"
@@MrJason005 That's essentially the idea behind Responsible Disclosure, and likely what happened here. Unless you want to be an asshole to the entire world, you let the CPU makers know you've discovered a sploit like this quite some time before revealing it to all and sundry.
OK, trying to get my head around how you go from Ring 3 to Ring -2, _via Ring 0 which you've ALREADY cracked_ (the granting of Root to a Ring 3 process essentially just being a nice side effect and probably possible with the rootkit alone)... is the crucial thing the installation of that Rootkit, as a system driver? Thus making this actually a two-stage vulnerability: the extremely edge-case CPU attack is the second layer, and just as important is the security hole in either the operating system proper, or the user's head, allowing installation of (and thus granting of ring 0 privileges to) unsigned drivers one way or the other?
Since the SMM code can't be highjacked at run-time, how about changing the *actual* SMM code and injecting the rootkit there? 1. If the SMM code resides in ROM (EPROM, FLASH), the game would be over. 2. However the code shown in the presentation is self-modifying so SMM code resides in RAM and it must be writeable by the CPU. Let's explore what happens when the computer starts: The system memory contents in largely unpredictable (zeroes, FFs, garbage, operating system leftovers...) and thus no usable code may run from RAM until the computer loads something in it. Therefore if SMRAM resides in normal RAM (your trusty DIMMs), the system management code must be first copied there from BIOS memory (ROM/firmware) by the BIOS. That means that BIOS code needs to be able to override (disable) the MCH SMM memory protections so that it can copy the SMM code and data into RAM whilst *not* running in SM mode. If any SMI interrupt was triggered before the code is completely copied over, it would probably reset the machine so it's very likely the SMI interrupts need to be disabled by the BIOS until SMM is safe to execute. All the keys to this must lie in the computer firmware (the BIOS): the actual SMM code, the SMM initialization, MCH protection mechanism control, etc. It's quite possible that once MCH SMM memory protections are enabled by the BIOS, the protections can no longer be disabled by anything, i.e. it would be a one way hardware latch. However, this is just a conjecture. It would be worth the effort to disassemble (possibly after decrypting) the BIOS and SMM code and see how it's actually installed in RAM. Secondly, see if it's possible to modify the SMM code in the firmware image before flashing it. It is probably encrypted and digitally signed but the signature checks might be overridden by modifying the BIOS code checking them. Not easy but not impossible either. Since it took me just a while to come up with these ideas, I'm probably not the first to do so and these possible attacks have already been dealt with. 3. What happens if the computer has no DIMMs installed? Does the SMM code still run (perhaps from BIOS ROM)? Does power management, USB keyboard emulation and other SMM features work without DIMMs? If so, then it's very likely SMRAM resides in its own dedicated physical memory integrated into the chipset and not in DIMMs. Anyway, these are just my ideas after watching this jaw-dropping presentation at 2am. :)
> It would be worth the effort to disassemble (possibly after decrypting) the BIOS and SMM code and see how it's actually installed in RAM. No need, just pull Coreboot source and read it...
I wonder how is the discovery of this type of vulnerability. Such thing could be a much more valuable asset than 'here is another exploit'. How is the process of finding such labyrinth of forgotten backdoors?
Mmh. Well, console games don't tend to have much in the way of security. At least, not the older ones. Granted things changed when you got operating systems and menus and stuff... But on an old school game console the game has absolute control over the system at the lowest level. Literally everything the game does is executing at the lowest privilege level possible. (not that those old processors even had any such security, but if they did this akin to getting everything running in ring 0) So naturally, since there is no innate security, any security that DOES exist is in the game code itself. And... Well, when every cpu cycle counts, why would you put security into a game that has exclusive control over the entire system anyway? The only thing you'd maybe try and secure is stuff that you know would be directly exploitable, such as a password save scheme. But even then it's not like you'd put serious security in it. Still... The kinds of arbitrary code execution that can be possible in some games, as well as the methods used to initiate it can be quite hilarious. XD
You can, if you follow these instructions, and it's an older Intel system or probably a current AMD one. Quite what you're going to do with it when you get there, though? This exploit is mainly useful for fucking up other people's machines, stealing their data, etc. You're not going to unlock some kind of secret 2x execution speed mode or a hidden 32GB of RAM or whatever. It's kind of like breaking into an exceptionally well-locked janitor's closet and finding a mop and some large bottles of industrial strength bleach, and that's about it.
Backdoor to ring -2? Who and why would ever want to implement that? Like, if NSA or whoever can make Intel do things, why wouldn't they just make them include NSA code in SMM straight up?
One ring to rule them all... So wait since the One Ring doesn't get found but founds itself, maybe Domas didn't found a a way to reach Ring -2, but Ring -2 founds a way to reach Domas...
HIs first attempt reminds me of Commodore 64 code, where you also sometimes make the processor execute code in IO registers... Not for the same purpose of course... just to save some cycles
Did you highlight the wrong entry in the GDTs? You have the null entry and then entry 0x8, and then 0x10 as the third entry. You have two between it...
I'm no expert, but at 28:15 he says the jump transitions from 16-bit protected mode to 32-bit protected mode. In 16-bit protected mode could the GDT entries be only half the size perhaps?
Vink no they are identical. The far jump selects the entry you want to jump to. The entry itself specifies whether the segment contains 16bit or 32bit code.
So you can install a rootkit that's quite literally _impossible_ to detect, because the processor architecture has been designed for that code to be impossible to access by anything, no matter what you do. And this isn't supposed to sound scary?
Wouldn't it help to add a few checks into the SMM interrupt routine? Are the numbers returned within a certain range? Maybe add some changing (as in stack protection) magic numbers where the APIC doesn't have its writable registers?
Well, that's essentially what Intel have implemented, at the hardware level. The two memory ranges can no longer be set as overlapping, as of hardware coming out of its factories from about five years ago onwards. Implementing similar on older systems would require a firmware update to the EFI BIOS, and, well ... when was the last time _you_ bothered checking for one of those and installing it? Even though you're probably a fairly computer savvy person with security in mind? Even back in the bad old days when a motherboard's supplied firmware could be ropey as hell and require an update just to make certain built in features work correctly, you needed an internet connection to do that, to know that it was likely the cause of your trouble, and to go looking for it on the manufacturer's website. Then undergo a rather messy and risky process to reflash it. It's a little easier and more reliable these days, but I'd expect the knowledge of the need or even ability to do that amongst the general computer-using public to be effectively nil. Like, maybe a couple of percent, and the proportion of _those_ who actually bother to be about as small. Thus even if everyone who knew about the vuln and could be bothered to apply it did so, you'd be fishing in a pretty big pool of unpatched systems. Add to that the fact that the people who are more likely to patch their firmware are also amongst the earlier-adopter crowd and will have replaced their CPU by now anyway, and you have the only remaining potentially-vulnerable systems being almost universally wide-open to the hack.
i would assume that one begins with an instruction like mov ds zero mov ds[zero] zero kidding aside, you should check out his talks on how to make reverse engineers rage quit (he made a few; I love the one that makes Ida Pro windows a pixel buffer). Here's movfuscator, specifically: ruclips.net/video/R7EEoWg6Ekk/видео.html
Prometheus Return Orientated Programming, it's useful when you can't modify what's in the memory but you can control the pointer. It's actually how some of the first e-Voting machines in the US were pwned.
He kinda slides by the fact that you must have Ring 0 before you can Take over Ring -2. His first demo shows what you can do AFTER you have compromised the system. Overall scary great talk, but the misdirection in the first 10 minutes was a cheap coin trick.
I thought it was fixed back in the 90'th, the flaw was well documented in a 3x86-architecture guide book to be check by the basic operarating system (build386 this time). There where even an special interrupt and jump gate for this type of security problem.
kind of nevermind reading the rest of this. The attack is based on the Intel template EFI code. Just mung that in some way that breaks the SMM exploit but is otherwise harmless. You know, the same way practically all ring0 code is obfuscated. Do that. It seems just mitigate it by just ensuring that the only place ring0 code can be executed by the SMM doesn't contain malicious code. Just make sure that that segment always contains a specific piece of non-malicious data, and if it ever doesn't contain that, reset the system. It would make it close to impossible time-wise to ever _not_ reset the system by trying this exploit. You'd also have to leave most of the SMM code intact if you wanted an invisible backdoor, so just alter other parts of the SMM code to integrity-check the SMM code.
As he says in the video, there are at least three places to exploit the problem in the SMM code. If you "mung" one of them, more will be found. I'm not sure how you propose to ensure the SMM doesn't contain malicious code, I think antivirus vendors have been working on that one for years but still haven't cracked it. When you suggest integrity checking the SMM code, I think you might have missed the part of the presentation where he points out that no code is being modified, so any integrity check would pass as the code is unchanged.
I don't know, maybe I wasnt specific enough. SMM isn't code at all, its a processor state, but SM interrupts do _run_ code and that code lives in protected memory. The only way he presented to make use of this was to (eventually) jump to 0x00000000 and use ring0 to modify _that_ code. Push some kind of update to check and make sure that that only place you can force SMM to jump to contains something harmless. Yeah its bloat and polling won't catch everything, buts certainly better than nothing and in reality it would probably catch nearly all attacks. I mean keep in mind that the exploit is already assuming you have access to ring0 which you need to remap APIC memory. Also: he didn't mention 3 places the SMM could be exploited. He mentioned 3 things he tried and 2 of them don't work. One did. There's only one exploit presented in this video unless I missed something after 42:20, which is where I stopped. x86 assembly is not my wheelhouse. I have done some, but mostly just using SSE instructions to speed up math shit. There's a lot of people who know a lot more than me and a lot who know a lot less and I don't know where you fit in on that scale.
Probably be enough to patch the memory hub microcode so that location 0 (which is usually used for booting and maybe some interrupt vectors, rarely much in the way of even kernel let alone user code) is protected other than in certain very specific conditions that completely exclude user code, and maybe even OS code beyond the very earliest stages of booting? Or even keeping it off limits to anything in ring 0 or above, so only the hypervisor and SMM can touch it at all? Then if you force a jump to it, it just acts as if either you've performed a warm reset, or have triggered off an NMI and it ends up running some fairly innocuous driver or other system housekeeping code, dropping harmlessly back out of SMM afterwards without ever coming close to executing arbitrarily dropped-in instructions.
@@markpenrice6253 you mean the first 64K... something of a larger chunk to mess with. And as it needs to be writeable by the ring 0 OS anyway (unless we absolutely reserve it for Ring -1 and -2 functions, and force the OS to load higher), it'd still be vulnerable to a malicious rootkit driver.
@@markpenrice6253 > Or even keeping it off limits to anything in ring 0 or above Also known as "let's just break all x86 compatibility". Before you try to design a fix, you need to know what you are talking about.
Around the 21 minute mark - I'd be curious to know if he got any inspiration from the Super Mario World speedrun glitch where they used game state to code an overflow. ruclips.net/video/HxFh1CJOrTU/видео.html edit nevermind this was 2 years ago
Chris Terry let's be realistic, sethbling, and I assume what you linked is sethblings video, is nowhere near smart enough to do this himself. He's by no means dumb, but he isn't like the guy in this video.
he did it on non root account and just gain root access whiteout the hardware secure platform trigger on hard and kernel/hypeadrvisor ever notice. The only lowest on newest machines will be infect the intel management engine/bios the cpu starts whit the shit inside and there is not way detect a shit like that, this ones is the same run code outside the system.
You are in partial control at ring 0 - a big one, but still not complete. He mentions that at 7:20 - "if you think you are in control at ring 0, you are aren't even close."
He doesn't. The talk is about privilege escalation from ring 0 to ring -2 In his demo he isn't escalating to ring -2, but instead escalating from ring 3 to ring 0 with the smm rootkit that he (partly) made.
Yeah, that threw me as well. The opening of the talk is about reaching ring 0, ie OS kernel / root account from ring 3, plain old non-admin user space. Then suddenly we're starting from ring 0 and jumping up to ring -2 instead? How do those two things gel together? Oh hey I've got a way you can break you out of prison to roam free within the boundaries of your home country... _oh, cool, how do I do that then?_ Well, it's simple. You start from outside the prison, then you use this trick to cross the border and head out into international waters on a boat. ...uhhhh OK. If we've _already_ got ring 0 access, in order to install the kit, what's the point of being able to break into ring 0 from ring 3?
Having watched it a couple times and learned a little about rootkits on the side, I guess the crucial thing is that the main exploit installs as a driver? Thus the real vuln is in the OS driver installation functions not checking for signatures (or having weak and easily faked sigs), or in the end user installing random crap despite getting a UAC (or similar) popup out of nowhere warning them that something was trying to alter the system files. No unsigned driver installation, no hook for the rootkit to launch from. The userland program can do what it likes, without breaching security, because there's nothing sitting there waiting to receive the magic cookie and perform the necessary subterfuge within the processor, which then takes you from Ring 3 to Ring -2 _via_ an existing, smaller Ring 0 exploit. Thus if you're not really bothered with anything Ring -2 can do, you can just modify the interstitial rootkit and pwn the OS using that instead.
Every time I see code or tool tips in videos I try to highlight/copy/click off tool tips. ARGH! Too much time at the coal face... (nah - no such thing!)
My most favorite is Ems memory with page frame addressing cc00-efff. But that's my level in Windows. My level in ubuntu you can walk through encryption you can create iso's you can sudo level UMA for ram giving your laptop graphics shared more mb.
Old Intel processors: vulnerable to rootkits
New Intel processors: shipped with rootkits
🤣🤣🤣
this blew me away. dude looks like Cypher from The Matrix, too.
they really sent him back famous, not an actor though.
This guy essentially started the whole Intel CPU security fiasco nowadays... Before this day, no one thought the CPU could be this vulnerable.
Indeed. Check his Linkedin... Started working for Intel as senior security researcher in 2018... I bet they made him quite an offer. This guy was too dangerous to them to remain on the outside.
@@Degenerate76 Nah, he probably wanted to join too. He has access to lot of resources and a community of like minded people now
@@cortexauth4094 Sounds a lot like a win-win. He gets paid up the nose to work on interesting stuff and Intel get their shit patched
@@TheMrKeksLp yea this guy is awsome!
@@TheMrKeksLp yeah, it's not like they have a patent on a backdoor
I like the "oh btw I made a c compiler that only compiles to mov instructions". Jesus Christ......
Yeah lol I feel like a total amateur right now
Yeah, that was last years presentations....
"oh and one more thing, I'm able to make IDA display selfies"
the movfuscator is awesome lol, but you should check out trapcc. 0 instructions.
the way I interpreted it was that he made a brainfuck to MOV only asm compiler then decided to make a C to brainfuck or C to MOV only asm compiler. either way the optimization would be terrible unless that was all you had to work with.
Of course, change that last 3 to a 4 to root that system. Every presentation this guy gives is amazing!
You need to get the root kit installed from ring 0 first...
This Guy is a Frickin God
That's funny because in Defcon 2018 he calls the particular MSR bit that enables him to unlock the processor as the "God mode bit".
Never give your IP address to this guy, under any circumstances! :P
We all are . What do you think keeps our heart going. If you believe in separation you get it just those who lost in the 1929 crash with a heart attack. Enjoy.. I will debate no further. To each his own journey.
@Sam Rocks the exploiters are all outta Russia, China, and NSA though.
He is not god but gifted by god. It seems, there are much more flaws in the x86 design, as we think.
I've worked my way back from more recent talks to here, and every single talk by this guy is awesome, he's just amazing. Half the time I'm just sitting here in disbelief with a stupid grin on my face.
This guy is of a special breed... not many left like him.. to get into ring -2 with 4 BYTES of code is God like.
all of them
that's not some stuff you learn in classes.
but electronics engineering, processor architecture and embedded stuff may help you. and maybe some yoga and meditation to learn to handle the frustration of debugging stuff for hours and hours.
and please, just keep in mind, that guy write a compiler which compiles C into a bunch of mov operation, or figured out a way to flip people the finger when they look at his code in IDA.
@Reyes25111 6.004, 6.035, 6.828 on ocw is a good start
morgulbrut
What does that men’s c complied to mov ..
Like why is it so big deal
@@ko-Daegu exactly what I wrote. If you look at the assembly, compiled with that compiler, you only gonna see tons of mov instructions. Which makes it super annoying to reverse engineer.
27:35 validate the limit: `8026: test ax,ax; jz invalid_gdt`, validate the base: `802F: test eax,eax; jz invalid_gdt` - Can be mitigated with BIOS flash.
lol the talk was just amazing... the selfie was the cherry on top.
also unrelated I see that RUclips has bee messing around with their suggestion algorithm... most of the comments are no older then 2 days, most of them are less then 24h old, while the video is from 2016 (kinda) and originally only had three comments.
Lol! Perfect bug for sales. "All old processors are vulnerable and can't be fixed. Quick! Buy our new crap!"
"really this is unpatchable" and i believe him. this guy was talking alien to me
I had sworn the introducer walked away and came back. But then I rewinded it and saw the beard differed
Brilliant find but since it requires Ring 0 access to implement the rootkit you need to work along other exploits to get to that level - or secret services modifying whole shipments prior of delivery.
i do miss this guy, hope hes done some amazing things while working at intel. rosenbridge was never released, I guess what he stumbled upon was so powerful and so close to getting the concept to work.
This is probably the 1337est presentation I've watched. If you know of a crazier (or even comparable) hack please please please, let me know.
cbrpnk Rowhammer.
Very, very impressive stuff...
Watch more of his presentations and other Blackhat/Defcon/CCC(media.ccc.de on youtube) videos. also there is www.phrack.org/ :D so many cool things, stop watching and just do some hacking yourself ;) I cant staph watching hours of these
Alt + F4
Be aware of the exact time when to hit Delete/F2 only ONCE to access BIOS.
On a scale of 1 - 10 how genius is this guy?
Yes.
This is a Beautiful thing.
"We must go deeper." Ringception?
Sounds like a hitech rim job.
People like this are invaluable
the brother hood of nod selected
+ttfd little late to get friends with 88 doc.
Great talk. And also very lucky that the SMM code was written in a way that helped sinkhole.
While on the other hand, self-modifying code is the foundation of all modern anti-tempering protection used on software and games.
There is an error at 3:25, when he typed the last `whoami` it should have said:
# whoami
God
I was grinning like a maniac while watching this. An incredible finding. Bloody brilliant!
If you can't punt the ball - move the field ...
I was good until about 0:01 and then it stopped making sense.
How does this not have dozens of times the views???
ty chris domas - this & the hidden risc core in x85; such awesome research. lol so d0pe!
you are a beautiful creature domas!
a gestalt vulnerability, interesting
amazing talk
If Intel fixed the issue in Sandybridge, doesn't that imply that they were aware of the issue at some point prior to Sandybridge's release?
Given the wide-reaching implications of this exploit (a Ring 0 breach elevating to Ring -2 potentially renders the system hardware itself untrustable from that point forwards), shouldn't Intel have immediately disclosed knowledge of this flaw so that security policies could be updated to account for the increased scope of vulnerability?
Maybe they did disclose it, but only to selected parties while they worked out a solution. If they didn't, maybe that was because it would make little sense making it public if at that time they were certain nobody else knew about it yet, or at least nobody about whom they need worry. Meanwhile, they work out a solution and plan a future arch fix. Reminds me a little of when Bletcheley Park discovered imminent attacks via broken Enigma messages (city bombings, sub attacks, etc.), but they could not act on the information because that would give away the fact that Enigma had been cracked (vaguely recall Coventry was one such target); people had to be allowed to die to keep the cracking of Enigma secret and thus useful. Sometimes it's better to stay quiet, and meanwhile work out very carefully who needs to know and when.
I expect the first Intel would have told would be the NSA, etc. Good question to ask though! Obviously a very difficult area to define in terms of policy and actions/response. There are probably disclosure procedures in place that are not public; bit like there are parts of the UK's OSA which are secret. :D ie. I would be surprised if Intel did not have (already) relevant arrangements in place with security agencies, and then later the OEMs, etc., but if they do, it makes sense for any such procedures to not be in the public domain.
or really they should have kept it hush-hush so it wouldn't spread like wildfire to hackers who wanted to abuse it for bad, and only disclose it *after* it was "fixed"
@@MrJason005 That's essentially the idea behind Responsible Disclosure, and likely what happened here. Unless you want to be an asshole to the entire world, you let the CPU makers know you've discovered a sploit like this quite some time before revealing it to all and sundry.
OK, trying to get my head around how you go from Ring 3 to Ring -2, _via Ring 0 which you've ALREADY cracked_ (the granting of Root to a Ring 3 process essentially just being a nice side effect and probably possible with the rootkit alone)... is the crucial thing the installation of that Rootkit, as a system driver? Thus making this actually a two-stage vulnerability: the extremely edge-case CPU attack is the second layer, and just as important is the security hole in either the operating system proper, or the user's head, allowing installation of (and thus granting of ring 0 privileges to) unsigned drivers one way or the other?
It takes a lot of dedication, intelligent, and craziness to test this out
Heh, unreal mode. 32-bit addressing without memory protection of any kind. Pretty much the backbone of XMS memory.
Absolutely brilliant presentation. Stunning!
Since the SMM code can't be highjacked at run-time, how about changing the *actual* SMM code and injecting the rootkit there?
1. If the SMM code resides in ROM (EPROM, FLASH), the game would be over.
2. However the code shown in the presentation is self-modifying so SMM code resides in RAM and it must be writeable by the CPU.
Let's explore what happens when the computer starts:
The system memory contents in largely unpredictable (zeroes, FFs, garbage, operating system leftovers...) and thus no usable code may run from RAM until the computer loads something in it.
Therefore if SMRAM resides in normal RAM (your trusty DIMMs), the system management code must be first copied there from BIOS memory (ROM/firmware) by the BIOS.
That means that BIOS code needs to be able to override (disable) the MCH SMM memory protections so that it can copy the SMM code and data into RAM whilst *not* running in SM mode.
If any SMI interrupt was triggered before the code is completely copied over, it would probably reset the machine so it's very likely the SMI interrupts need to be disabled by the BIOS until SMM is safe to execute.
All the keys to this must lie in the computer firmware (the BIOS): the actual SMM code, the SMM initialization, MCH protection mechanism control, etc.
It's quite possible that once MCH SMM memory protections are enabled by the BIOS, the protections can no longer be disabled by anything, i.e. it would be a one way hardware latch. However, this is just a conjecture.
It would be worth the effort to disassemble (possibly after decrypting) the BIOS and SMM code and see how it's actually installed in RAM.
Secondly, see if it's possible to modify the SMM code in the firmware image before flashing it. It is probably encrypted and digitally signed but the signature checks might be overridden by modifying the BIOS code checking them. Not easy but not impossible either.
Since it took me just a while to come up with these ideas, I'm probably not the first to do so and these possible attacks have already been dealt with.
3. What happens if the computer has no DIMMs installed? Does the SMM code still run (perhaps from BIOS ROM)? Does power management, USB keyboard emulation and other SMM features work without DIMMs? If so, then it's very likely SMRAM resides in its own dedicated physical memory integrated into the chipset and not in DIMMs.
Anyway, these are just my ideas after watching this jaw-dropping presentation at 2am. :)
> It would be worth the effort to disassemble (possibly after decrypting) the BIOS and SMM code and see how it's actually installed in RAM.
No need, just pull Coreboot source and read it...
I wonder how is the discovery of this type of vulnerability. Such thing could be a much more valuable asset than 'here is another exploit'. How is the process of finding such labyrinth of forgotten backdoors?
If you're interested in the thought process of a pen tester, you need absolutely to watch channel LifeOverflow
This really reminds me of arbitrary code execution in console games.
Mmh. Well, console games don't tend to have much in the way of security. At least, not the older ones.
Granted things changed when you got operating systems and menus and stuff...
But on an old school game console the game has absolute control over the system at the lowest level.
Literally everything the game does is executing at the lowest privilege level possible. (not that those old processors even had any such security, but if they did this akin to getting everything running in ring 0)
So naturally, since there is no innate security, any security that DOES exist is in the game code itself.
And... Well, when every cpu cycle counts, why would you put security into a game that has exclusive control over the entire system anyway?
The only thing you'd maybe try and secure is stuff that you know would be directly exploitable, such as a password save scheme.
But even then it's not like you'd put serious security in it.
Still... The kinds of arbitrary code execution that can be possible in some games, as well as the methods used to initiate it can be quite hilarious. XD
@@KuraIthys It's the "making code do what it shouldn't by sending small amounts of data into a specific part of memory" that's similar
Amazing work. Also somewhat terrifying.
Great talk. Great speaker
Mind boggling. And terrifying.
awe :( I was hoping to get ring -2 access to my pc
You can, if you follow these instructions, and it's an older Intel system or probably a current AMD one.
Quite what you're going to do with it when you get there, though? This exploit is mainly useful for fucking up other people's machines, stealing their data, etc. You're not going to unlock some kind of secret 2x execution speed mode or a hidden 32GB of RAM or whatever.
It's kind of like breaking into an exceptionally well-locked janitor's closet and finding a mop and some large bottles of industrial strength bleach, and that's about it.
Does it affect my abacus?
"design flaw" is a funny way of saying backdoor .-.
Backdoor to ring -2? Who and why would ever want to implement that? Like, if NSA or whoever can make Intel do things, why wouldn't they just make them include NSA code in SMM straight up?
This i by far the most insane exploit i've seen so far
This guy...
And here we have Kane, before he gets involved with the Nod
Who says he isn't?
3:01 magic
Really good talk!
Outstanding work
Wow, that was beautiful. But seriously, Lord of the Rings, i.e. Intel, how many rings do we need? In 10 years there'll be ring -10.
Lord of the Rings, eh? You mean that story about Frodo dumping ring -2 into the zeroes of Mount APIC?
One ring to rule them all... So wait since the One Ring doesn't get found but founds itself, maybe Domas didn't found a a way to reach Ring -2, but Ring -2 founds a way to reach Domas...
fantastic talk
soon there will be Ring -9999
HIs first attempt reminds me of Commodore 64 code, where you also sometimes make the processor execute code in IO registers... Not for the same purpose of course... just to save some cycles
Did you highlight the wrong entry in the GDTs? You have the null entry and then entry 0x8, and then 0x10 as the third entry. You have two between it...
dascandy I spotted that too. I ts an easy mistake to make though
I'm no expert, but at 28:15 he says the jump transitions from 16-bit protected mode to 32-bit protected mode. In 16-bit protected mode could the GDT entries be only half the size perhaps?
Vink no they are identical. The far jump selects the entry you want to jump to. The entry itself specifies whether the segment contains 16bit or 32bit code.
Didn't he say Long Mode, which is 64-bit? Or am I mixing up videos?
So you can install a rootkit that's quite literally _impossible_ to detect, because the processor architecture has been designed for that code to be impossible to access by anything, no matter what you do. And this isn't supposed to sound scary?
Not to the three letter agency which installs the root kit before the computer is shipped to you
Any suggestion for hardware/software tools for hack/reversing?
Beastmode.
Wouldn't it help to add a few checks into the SMM interrupt routine? Are the numbers returned within a certain range? Maybe add some changing (as in stack protection) magic numbers where the APIC doesn't have its writable registers?
Well, that's essentially what Intel have implemented, at the hardware level. The two memory ranges can no longer be set as overlapping, as of hardware coming out of its factories from about five years ago onwards.
Implementing similar on older systems would require a firmware update to the EFI BIOS, and, well ... when was the last time _you_ bothered checking for one of those and installing it? Even though you're probably a fairly computer savvy person with security in mind?
Even back in the bad old days when a motherboard's supplied firmware could be ropey as hell and require an update just to make certain built in features work correctly, you needed an internet connection to do that, to know that it was likely the cause of your trouble, and to go looking for it on the manufacturer's website. Then undergo a rather messy and risky process to reflash it. It's a little easier and more reliable these days, but I'd expect the knowledge of the need or even ability to do that amongst the general computer-using public to be effectively nil. Like, maybe a couple of percent, and the proportion of _those_ who actually bother to be about as small.
Thus even if everyone who knew about the vuln and could be bothered to apply it did so, you'd be fishing in a pretty big pool of unpatched systems. Add to that the fact that the people who are more likely to patch their firmware are also amongst the earlier-adopter crowd and will have replaced their CPU by now anyway, and you have the only remaining potentially-vulnerable systems being almost universally wide-open to the hack.
pure sorcery.
For a malicious virus, you could make a fake driver that installs the Ring -2 rootkit. Drivers run in Ring 0 (or ring 1 or ring 2 on really old OSes).
Cipher himself.
isn't ring 0 like the most root ring? negative rings for vm's and positive for normal apps?
Rings are an illusion. It's a number that simply defines the IO privileges, 0, 1, 2 can do IO instructions, 3 can't.
But can you do it in 0x A Presses?
How does one even go about making a mov instruction compiler...? Is there some sort of BNF notation on how it interprets stuff?
i would assume that one begins with an instruction like
mov ds zero
mov ds[zero] zero
kidding aside, you should check out his talks on how to make reverse engineers rage quit (he made a few; I love the one that makes Ida Pro windows a pixel buffer). Here's movfuscator, specifically: ruclips.net/video/R7EEoWg6Ekk/видео.html
Going beyond the 68k instruction set was a mistake
The 68000 and 8086 came out pretty much at the same time as each other, so I'm not sure what your point is.
Risc, save us.
Impressive !!
Mind = blown
Rewrite that using only mov instructions. :D
24:40 What is ropping? I don't understand the phrase "APIC-ropping"
ROPping == Return-oriented programming
What is ropping?
Prometheus Return Orientated Programming, it's useful when you can't modify what's in the memory but you can control the pointer. It's actually how some of the first e-Voting machines in the US were pwned.
+MrPindi05 interesting, do u have more info on that?
@@MrPindi05 bump
He kinda slides by the fact that you must have Ring 0 before you can Take over Ring -2. His first demo shows what you can do AFTER you have compromised the system. Overall scary great talk, but the misdirection in the first 10 minutes was a cheap coin trick.
It's not hard to get a user to install a driver that runs this rootkit.
At a time of writing this comment, there were 30 high-positioned intel employees watched this video.
By design
I thought it was fixed back in the 90'th, the flaw was well documented in a 3x86-architecture guide book to be check by the basic operarating system (build386 this time). There where even an special interrupt and jump gate for this type of security problem.
How could it be fixed on the 386 when the APIC wasn't introduced until after the Pentium?
kind of nevermind reading the rest of this. The attack is based on the Intel template EFI code. Just mung that in some way that breaks the SMM exploit but is otherwise harmless. You know, the same way practically all ring0 code is obfuscated. Do that.
It seems just mitigate it by just ensuring that the only place ring0 code can be executed by the SMM doesn't contain malicious code. Just make sure that that segment always contains a specific piece of non-malicious data, and if it ever doesn't contain that, reset the system. It would make it close to impossible time-wise to ever _not_ reset the system by trying this exploit.
You'd also have to leave most of the SMM code intact if you wanted an invisible backdoor, so just alter other parts of the SMM code to integrity-check the SMM code.
As he says in the video, there are at least three places to exploit the problem in the SMM code. If you "mung" one of them, more will be found. I'm not sure how you propose to ensure the SMM doesn't contain malicious code, I think antivirus vendors have been working on that one for years but still haven't cracked it. When you suggest integrity checking the SMM code, I think you might have missed the part of the presentation where he points out that no code is being modified, so any integrity check would pass as the code is unchanged.
I don't know, maybe I wasnt specific enough. SMM isn't code at all, its a processor state, but SM interrupts do _run_ code and that code lives in protected memory. The only way he presented to make use of this was to (eventually) jump to 0x00000000 and use ring0 to modify _that_ code. Push some kind of update to check and make sure that that only place you can force SMM to jump to contains something harmless. Yeah its bloat and polling won't catch everything, buts certainly better than nothing and in reality it would probably catch nearly all attacks.
I mean keep in mind that the exploit is already assuming you have access to ring0 which you need to remap APIC memory.
Also: he didn't mention 3 places the SMM could be exploited. He mentioned 3 things he tried and 2 of them don't work. One did. There's only one exploit presented in this video unless I missed something after 42:20, which is where I stopped.
x86 assembly is not my wheelhouse. I have done some, but mostly just using SSE instructions to speed up math shit. There's a lot of people who know a lot more than me and a lot who know a lot less and I don't know where you fit in on that scale.
Probably be enough to patch the memory hub microcode so that location 0 (which is usually used for booting and maybe some interrupt vectors, rarely much in the way of even kernel let alone user code) is protected other than in certain very specific conditions that completely exclude user code, and maybe even OS code beyond the very earliest stages of booting? Or even keeping it off limits to anything in ring 0 or above, so only the hypervisor and SMM can touch it at all? Then if you force a jump to it, it just acts as if either you've performed a warm reset, or have triggered off an NMI and it ends up running some fairly innocuous driver or other system housekeeping code, dropping harmlessly back out of SMM afterwards without ever coming close to executing arbitrarily dropped-in instructions.
@@markpenrice6253 you mean the first 64K... something of a larger chunk to mess with. And as it needs to be writeable by the ring 0 OS anyway (unless we absolutely reserve it for Ring -1 and -2 functions, and force the OS to load higher), it'd still be vulnerable to a malicious rootkit driver.
@@markpenrice6253 > Or even keeping it off limits to anything in ring 0 or above
Also known as "let's just break all x86 compatibility". Before you try to design a fix, you need to know what you are talking about.
Def a wizard, the different hats, this magic it all makes sense now.
AMD's backdoor is finally coming into the spotlight.
this is some fascinating shit
Around the 21 minute mark - I'd be curious to know if he got any inspiration from the Super Mario World speedrun glitch where they used game state to code an overflow. ruclips.net/video/HxFh1CJOrTU/видео.html
edit nevermind this was 2 years ago
Chris Terry let's be realistic, sethbling, and I assume what you linked is sethblings video, is nowhere near smart enough to do this himself. He's by no means dumb, but he isn't like the guy in this video.
I'm not sure I understand the point of this. You start in Ring 0 which means you already control the system.
he did it on non root account and just gain root access whiteout the hardware secure platform trigger on hard and kernel/hypeadrvisor ever notice.
The only lowest on newest machines will be infect the intel management engine/bios the cpu starts whit the shit inside and there is not way detect a shit like that, this ones is the same run code outside the system.
The point is if you get in once you're in forever.
You are in partial control at ring 0 - a big one, but still not complete. He mentions that at 7:20 - "if you think you are in control at ring 0, you are aren't even close."
I must've missed how he wrote to address 0 from Ring 3? Anyone catch that?
He doesn't. The talk is about privilege escalation from ring 0 to ring -2
In his demo he isn't escalating to ring -2, but instead escalating from ring 3 to ring 0 with the smm rootkit that he (partly) made.
He did it from ring 0. You have to be in ring 0 to install the rootkit. Once it's running you can signal it from ring 3.
Now it's possible to access ring 0 from ring 3 have a look at youtube vid v=_eSAF_qT_FY
Yeah, that threw me as well. The opening of the talk is about reaching ring 0, ie OS kernel / root account from ring 3, plain old non-admin user space. Then suddenly we're starting from ring 0 and jumping up to ring -2 instead? How do those two things gel together?
Oh hey I've got a way you can break you out of prison to roam free within the boundaries of your home country... _oh, cool, how do I do that then?_ Well, it's simple. You start from outside the prison, then you use this trick to cross the border and head out into international waters on a boat.
...uhhhh OK.
If we've _already_ got ring 0 access, in order to install the kit, what's the point of being able to break into ring 0 from ring 3?
Having watched it a couple times and learned a little about rootkits on the side, I guess the crucial thing is that the main exploit installs as a driver? Thus the real vuln is in the OS driver installation functions not checking for signatures (or having weak and easily faked sigs), or in the end user installing random crap despite getting a UAC (or similar) popup out of nowhere warning them that something was trying to alter the system files.
No unsigned driver installation, no hook for the rootkit to launch from. The userland program can do what it likes, without breaching security, because there's nothing sitting there waiting to receive the magic cookie and perform the necessary subterfuge within the processor, which then takes you from Ring 3 to Ring -2 _via_ an existing, smaller Ring 0 exploit.
Thus if you're not really bothered with anything Ring -2 can do, you can just modify the interstitial rootkit and pwn the OS using that instead.
I saw this guy eating steak with Agent Smith in the Matrix.
Hail Domas!
why do all the speakers at black hat conferences use windows? when clearly a lot of their work in done on linux / in unix environments?
He also used Ubuntu, which is a GNU/Linux distro
Next level
Lets just start all over and make ring 4 and everything goes there
Cool! This will make my crypto mining malware so much better!
This video sends actual chills up my spine, to this day
what a god.
my mind is blown
"Now, attempt to imagine the limitlessness of God's knowledge code"
My computer just became a doorstop.
i miss coding as much as finding stuff like this out. never got right into x86+ but i respect this guys thought processes
How the hell does he know all of this stuff?
he is a regular on Black Hat. Check out his x86 Instruction Set fuzzing. ruclips.net/video/KrksBdWcZgQ/видео.html
I just found out what I want to do with my life.
Whaaat the fuuuuck
How Does The Ve Keep The Hat Going On Industrial Encroachment Of The Growth Sector ?
Every time I see code or tool tips in videos I try to highlight/copy/click off tool tips. ARGH! Too much time at the coal face... (nah - no such thing!)
What keeps me working is nes roms and their memory locs.
My most favorite is Ems memory with page frame addressing cc00-efff. But that's my level in Windows. My level in ubuntu you can walk through encryption you can create iso's you can sudo level UMA for ram giving your laptop graphics shared more mb.
Boss lvl 99 ?!