Check it out for more about the first-in-the-world work @coreykal & Rafal Wojtczuk have done for UEFI DMA protection and UEFI sandboxing of PCIe Option ROMs
@coreykal@NikolajSchlej Enabling VT-d before there's even RAM available? It's what you gotta do ¯\_(ツ)_/¯
@coreykal@NikolajSchlej Moving from a monolithic ring 0, anyone-who-gets-in-wins memory space to the ring 0/ring 3 + virtual memory separation we depend on in all other contexts? Sure, why not
• • •
Missing some Tweet in this thread? You can try to
force a refresh
🧵Tl;dr: the below is a fork with updated instructions on running @_markel___, @h0t_max, & @_Dmit’s Apollo Lake TXE exploit PoC on AAEON UP Squared boards (since you can buy them currently, but you can’t buy the original targeted boards)
Longer version: I had never got playing with this exploit back when it came out, since I didn’t really care about CSME that much while at Apple since we had an extra-minimized version that was only used for PAVP, and caring about that was a different team’s purview
“From a security perspective, these machines may possibly qualify as the most secure general purpose computers available to the public which support third-party OSes, in terms of resistance to attack by non-owners.”
High praise indeed. Examination of a few key points below 🧵
“The entire architecture is complicated and the details subtle”
It’s true, some of the design goals like per-OS policies were ambitious and difficult to achieve. And very subtle attacks were considered and combatted, which required a bit of gymnastics...
I sort of suspect that the subtler the attack defense, the more likely it will be that it will break over time. E.g. there was a major architectural change in how recoveryOS works between macOS 11 and 12 which increased complexity by going from 1 recoveryOS to N paired rOSes.
According to my calendar it took me about 30h30m over 6 days to understand and then write up CVE-2020-29661. This has def taken ~50% longer than other #OST2 Vuln1001 vuln+example writeups, since I have no background in Linux kernel exploits, so I had to read lots of other docs
About half the time was understanding and then half writing it back up in pretty form. (There were no diagrams in the original writeup!) But also I suspect the actual videos will be about 50% longer too (since the number of slides is about 50% larger than some other examples).
In any case…that was highly exhausting and I hope to avoid that LoE for future vuln+exploit walkthroughs! But on the plus side, the class is highly extensible because I or my collaborator @glitchnsec can just add newer examples as they appear, or older examples as the mood suits
🧵 I’m starting to get a sneaking suspicion that a lot of things people call normal TOCTOU are a sub case of double fetch, and not vice versa as has historically been claimed… A lot of the “non-double-fetch TOCTOU” I’m dredging up are around things like signature verification…
However, if you e.g. verify a signature, and then execute a signed thing, the execution is *implicitly* a second fetch (just by the OS). If you had pulled the content in to a no-longer-attacker-manipulatable area that didn’t require a second fetch, then there wouldn’t be a vuln
Does anyone have a good TOCTOU example that they think *doesn’t* involve an explicit or implicit second fetch?
Request for help: I’ve decided that my next #OST2 class will be on C/C++ vulnerabilities, but I could use some help sorting through recent CVEs to find good examples (where good means newish, and applicable to a diverse set of environments). More details in the thread…
Note that I said the class is about vulnerabilities, not exploits. The goal of the class will be to create material that is equally applicable to developers who need to learn how to avoid writing the bugs, as it is to folks who will want to learn how to exploit them.
(The class is basically all the various vulnerability classes shown to the left on this learning path: drive.google.com/file/d/1k4TbLv…. The part I’m looking for help with is picking the specific CVEs that will fill in the “N examples” portion of that diagram)
I have another thought on OST2 all-you-can-learn buffet classes that I wanted to share separate from that other thread, since this will probably be a future blog post: Another eventual goal is to use them to hand over the reins for my material to a new instructor
Basically you can imagine having someone else who knows x86-64 assembly very well acting as a “TA” in some larger OST2-B (ost2.fyi/Thoughts-on-OS…) classes, helping to answer questions. Because the key thing is that an instructor should know the material well enough to explain it
Regardless of what curveball questions students ask. Or alternatively if they don’t know, they should be able to go look it up or determine the answer experimentally while the student goes back to watching videos, before getting back to them with an answer