🧵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)

github.com/XenoKovah/Inte… 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 🧵

https://twitter.com/marcan42/status/1504097192323465216

“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...

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

https://twitter.com/xenokovah/status/1489622745772134403

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).

🧵 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

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.

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

There’s one week left to register for the first-ever in-person #OST2 all-you-can-learn buffet class on x86-64 assembly, OS internals, and firmware: hardwear.io/netherlands-20… There’s a lot of open questions around this experiment, most notably “will students be interested in coming to an in-person training to get direct support instead of just taking the free online version?” And so far the answer seems to be yes

I just extracted the self-reported completion times data from the Architecture 2001: x86-64 OS Internals #OST2 beta class students who filled out all 10 entries, and it looks like the following. Some thoughts below… 1) This was originally created targeting about 2 days (~14 hours after subtracting lunch ;)) of in-person delivery. You can see a *few* students could do it in that time, but most needed more time. This is why I really like that I can now let students learn at their own pace

Thread: This would perhaps be a good time to point out that while it’s absolutely true that Windows’ UEFI SecureBoot is intentionally not designed to defend against physical presence, that’s actually an improvement I shot for with Mac SecureBoot, first on T2 and then M1

https://twitter.com/dwizzzleMSFT/status/1425495829511430145

I termed the security goal “P != X” meaning mere physical possession *in and of itself* should not equal code execution. Rather, possession must be combined with knowledge of an administrator password before you could disable that critical security feature.

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

https://twitter.com/radian/status/1197990878540775424

@coreykal Or for the work @NikolajSchlej and I did on bringing SecureBoot to the Mac

Thread: A while back I was asked to add SGX attack papers to the timeline. That seemed reasonable to me, so I started collecting them...and then got distracted before I had worked through cross-references and such... In general I'm not super interested in capturing the SGX/SideChannel category of papers, because they're mostly academic papers, which already do a good job of citation. So you can always just look at the end of the latest few papers to find most of the previous papers...