HN Theater @HNTheaterMonth

This is a thing and was used in this fantastic piece: https://www.youtube.com/watch?v=lR0nh-TdpVg

However the way they obtained these dumps is by going deep into debugger mode of the cpu which makes me doubt anything spooky would be going on.

⬐ genewitch

Ahh, I knew someone would post a reference or video of xorxorxorxor, or Mr. Domas.

I was so excited to try out sandsifter I spent an entire night shift compiling everything on a raspberry pi or rockchip.

Sandsifter is an x86 instruction dumper. Sometimes I wonder if the head injuries I took as a teen affected me in a subtle way, because I did watch the entire sandsifter presentation where he repeatedly says x86.

He also has a cool presentation about ring -1, -2, and beyond, of which the reader for that stuff was what I figured was used to find the actual OP.

⬐ tambourine_man

I’m usually not into security research but this is fascinating, thank you.

Someone screwing some C code and creating a vulnerability isn’t that interesting to me, but going on such low level and fundamental stuff makes me giddily, if not a bit scared.

Last time something like this caught my eye was that iMessage[1] NSO thing, not because they managed to escaped the sandbox, but because of the insanely clever way they did it.

[1] https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

⬐ sizzle

Same and also the state sponsored centrifuge destroying 0 day that was written up a while ago, super mind bending read

⬐ tambourine_man

Yes! That one too.

I can make an argument that money will make it even worse, as people will full-time make even more useless features that just increase the attack surface.

This particular class of problems (same as the sqlite fts tokenizer exploit and most of openssl exploits, even lots of the sendmail exploits) are just obscure unused features. It happens even in CPUs themselves. (e.g. https://www.youtube.com/watch?v=lR0nh-TdpVg)

Removing code is twice harder than adding code, why do you think paid maintainers would improve anything? Just look at the code written in FAANG or any enterprise, and those maintainers are very well paid, imagine this code being public, we will have 1 new exploit per day per company... and that is assuming non malicious developers that can be shipping trojan code https://lwn.net/Articles/874951/ (it is also hard to assume all millions of developers are non malicious, even if we assume 1 in 100000, things look really bad)

Less code is the one solution. Regardless if open source or enterprise code.

We are stuck, and change is needed, but money is not a solution, and might even be the cause of the problem. (incentive to write more code)

Chris Domas works at Battelle Memorial Institute. Battelle is a "non profit R&D house" that just so happens to hire "retiring" CIA operatives, and work on tons of CIA/NSA contracts.

Completely coincidentally Chris Domas managed to discover the only Intel CPU backdoor ever discovered and publicized the very same year Intel already patched it

https://www.youtube.com/watch?v=lR0nh-TdpVg

I can imagine some ways to armor the branch predictor, similar in principle to how languages like Perl have to include a random seed in their hash code (in some circumstances) to avoid being able to pre-compute values that will all hash to the same thing [1]. There should be some ways to relatively cheaply periodically inject such a randomization into the prediction system enough to prevent that aspect of the attack. This will cost something but probably not be noticeable to even the most performance-sensitive consumers.

But no solution leaps to mind for the problem of preventing speculative code from leaking things via cache, short of entirely preventing speculating code from being able to load things into the cache. If nobody can come up with a solution for that, that's going to cost us something to close that side channel. Not sure what though, without a really thorough profiling run.

And I'd put my metaphorical $5 down on someone finding another side channel from the speculative code; interactions with changing processor flags in a speculative execution, or interaction with some forgotten feature [2] where the speculation ends up incorrectly undone or something.

Yuck.

[1]: https://blog.booking.com/hardening-perls-hash-function.html

[2]: https://www.youtube.com/watch?v=lR0nh-TdpVg - The Memory Sinkhole - Unleashing An X86 Design Flaw Allowing Universal Privilege Escalation (Dec 29, 2015)

⬐ civilitty

AFAICT injecting any sort of delay that prevents this attack would also completely negate any benefit from caches and that would take us back to 2000s performance at best, even with 10-16 core Xeon monsters. The branch predictor is really just a glorified cache prefetcher so you'd not only have to harden the branch predictor but anything that could possibly access the cache lines that the branch predictor has pulled up.

⬐ jerf

"The branch predictor is really just a glorified cache prefetcher so you'd not only have to harden the branch predictor..."

I was just thinking of the part they were talking about where it was too predictable, not the rest of the issues. Instead of a single hard-coded algorithm we could switch to something that has a random key element, like XOR'ing a rotating key instead of a hard-coded one, similar to some of the super-basic hashing some predictors already do. Prefetching I just don't know what to do with. I mentally started down the path of considering what it would take for the CPU to pretend the page was never cached in the first place on a misprediction, but yeow, that got complicated fast, between cache coherency issues between processors and all of the other crap going on there, plus the fact that there's just no time when we're talking about CPU and L1 interactions.

Timing attacks really blow. Despite the "boil the ocean" nature of what I'm about to say, I find myself wondering if we aren't better served by developing Rust and other stronger things to the point that even if the system is still vulnerable to timing attacks it's so strong everywhere else that it's a manageable problem. Maybe tack on some heuristics to try to deal with obvious hack attempts and at least raise the bar a bit. More process isolation (as in other links mtanski gives you can at least confine this to a proces). (What if Erlang processes could truly be OS processes as far as the CPU was concerned?) I'm not saying that is anything even remotely resembling easy... I'm saying that it might still be easier than trying to prevent timing attacks like this. That's a statement about the difficulty of fixing timing attacks in general, not the easy of "hey, everybody, what if you just wrote code better?", a "solution" I often make fun of myself.

⬐ mtanski

I'm thinking you might be right.

It's going to be really hard to give up real world gains from branch prediction. Branch prediction can make a lot of real world (read "not the finest code in the world") run at reasonable speeds. Another common pattern to give up would be eliding (branch predicting away) nil reference checks.

> short of entirely preventing speculating code from being able to load things into the cache

Some new server processors allow us to partition cache (to prevent noisy neighbors) [1,2]. I don't have experience working with this technology but everything I read makes me believe this mechanism can works on a per process basis.

If that kind of complexity is already possible in CPU cache hierarchy I wonder if it's possible to implement per process cache encryption. New processors (EPYC) can already use different encryption keys for each VM, so it might be a matter of time till this is extended further.

[1] https://danluu.com/intel-cat/

[2] https://lwn.net/Articles/694800/

⬐ mtanski

This rant/thread is a good reading as well: https://lkml.org/lkml/2018/1/3/797

It's possible to key the cache in the kernel on CPL so at least there should be no user / kernel space scooping of cache lines.

It's possible we can never fully prevent all attacks in same address space. So certain types of applications (JIT and sandboxes) might forever be a cat and mouse game since we're unlikely to give up on branch prediction.

Then from recent Defcon and Black Hat talks, they are an absymal failure. ( https://www.youtube.com/watch?v=lR0nh-TdpVg Memory Sinkhole - Unleashing An X86 Design Flaw Allowing Universal Privilege Escalation ) (I don't understand it beyond what everyone says it can achieve)

Intel should be considered to be totally unreliable and incompetent.

I mean, no one buys office store safes and expects their things to be secure in them. But a processor is a little more expensive than a cheap safe and holds more valuable things.

Edit: and besides, Fortezza is an SSL protocol option.

⬐ standupstandup

SGX is designed to shield software against SMM exploits.

⬐ ryacko

>SGX is designed to shield software against SMM exploits.

Perhaps if we add one more thing, x86 will finally be secure. You are right, Intel should be left to their own devices.

⬐ hateduser2

Seems like you replied to the wrong comment, the intended parent might not see your reply because of this.. probably should repost it in the right place

⬐ ryacko

Hmm. I thought comment chains were limited in length.

⬐ hateduser2

Not that I know of.. although the reply button sometimes doesn’t show up.. you just have to click Into a comment if it’s missing for you

⬐ standupstandup

I'm not arguing that x86 will ever really be secure. However you handwaved a hypothetical "secure processor architecture". Realistically the way you do that is by making a very simple CPU, however, that would then be too slow to be usable for many applications. As a consequence nobody is doing so.

SGX is at least a middle ground - it integrates the memory access checks very deep into the memory access circuitry, sufficiently deep to block all other privilege levels on the CPU. Whilst there may well be implementation flaws in SGX itself so far most attacks have been mounted via side channels, not directly exploiting CPU bugs.

In this sense my original statement was correct. Intel is pushing secure CPUs forward more than any other vendor.

⬐ ryacko

I think a secure processor is very complex, not very simple. The smartest person's working memory cannot operate on more than a few hundred lines of code. A high performance processor that induces a fault when a programming error occurs is certainly very complex.

It is the wrong sense. Intel is playing catchup more than any other vendor and are selling a product that is nothing more than a bunch of cobbled together features, my opinion in the view of the statement that AMD is glued together.

⬐ nickpsecurity

They're actually pretty simple if you're mostly trying to defeat software/firmware attacks. You just add some part to run in parallel with the processor, which can be arbitrarily simple or complex, that checks certain things about the data such as length or data type. The first one was implemented in 1961 hardware with it being secure from code injection until the invention of ROP. That's a long time. I'll add a modern take on that which led to a flexible mechanism that can do a dozen or maybe more policies.

http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...

http://www.crash-safe.org/papers.html

A more complex one is below that was also designed by one person for his dissertation. Knocks out all kinds of issues without modifying the processor. It has stuff to improve for sure but it think it proves the point pretty well. The stuff corporate teams were designing comes nowhere near this because they don't know much about high-security design. A critical part of that isn't features so much as a balancing act between what protection mechanisms do and don't that tries to minimize complexity to low as is possible.

https://theses.lib.vt.edu/theses/available/etd-10112006-2048...

And one open-source one on MIPS for capability-based security that runs FreeBSD:

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

A company or group of hardware volunteers could develop this into something at least as usable as a multi-core ARM CPU on RISC-V or OpenSPARC. It wouldn't take tons of money esp if they worked their way up in complexity. The hard stuff is already done. People just need to apply it. They could even pay these academics to do it for them with open-sourced results. They even get a huge discount on the EDA tools that can be six digits a seat.

You're right that Intel is screwing up and playing catchup cobbling together features. There was stuff in the available literature better than most of what they're doing. They even have a separation kernel from Wind River they're not employing. Managers without security expertise must be pushing a lot of this stuff.

⬐ gggvvh

Ain’t no problem that couldn’t be solved by adding another layer of indirection, eh?

⬐ nickpsecurity

Maybe in web or application software. In hardware, it all runs in parallel. The mechanism of something like SAFE becomes another component receiving input in the CPU pipeline. A conditional of sorts is added so the final write back to whatever memory doesn't happen unless the safety/security checks passed. The failure mode might also do an interrupt for OS so it could log the where and why of the failure. As in, application flaws could be patched quickly.

⬐ ryacko

The theory is simple. I'm somewhat inclined to think it is not so easily applicable.

It is easy to make a secure coprocessor, since the formal logic proofs aren't for such a long set of code.

The fact that rootkits are even possible, that without malware that doesn't involve an elaborate rewrite of the kernel, shows how terrible everything is.

If I didn't know any better, I'd say that Intel is hiring the designers who thought Internet Explorer should be in the kernel.

> adding the possibility to turn it off should suffice.

How could Intel/AMD reasonably communicate this to customers and have it taken at face value?

"Here's a flag to disable this black box we ship in every CPU. The product design and source code are proprietary, so please take our word for it that this flag disables everything."

There was a blackhat talk on embedding malware in SMM and triggering it with a magic number written to a register to escalate the process privileges. [0] So there will always be suspicion of special triggers to re-enable the black box that you turned "off"

I think there is a very slim chance that Intel and AMD can regain credibility when it concerns the IME/PSP.

Especially after it emerged Intel created a special ME disabled mode intended for US agency customers. [1]

[0] https://youtu.be/lR0nh-TdpVg

[1] https://m.hardocp.com/news/2017/08/30/how_to_disable_intel_m...

⬐ gsich

Turning it off/on would have to be a jumper setting on the mainboard. BIOS won't do any good, as this is more a "software" setting. However, a jumper might have the same effect...

⬐ kogepathic

How would a jumper resolve fears that the black box is not totally disabled?

You're referring to something deeply embedded in silicon and firmware. This isn't a separate device you can easily depower through a jumper.

What about a laptop or tablet where there is no user accessible jumper?

⬐ gsich

You could if the developer wanted to.

A jumper on a laptop is not impossible. But to be honest, I haven't seen one in my Thinkpads.

Here is nice presentation about hacking intel ME in older processors

https://www.youtube.com/watch?v=lR0nh-TdpVg