Branch Privilege Injection: Exploiting branch predictor race conditions

Prepare for another dive maneuver in the benchmarks department I guess.

Ok, we've changed to that from https://ethz.ch/en/news-and-events/eth-news/news/2025/05/eth... above.

As far as I am aware, the course material is not public. Practical assignments are an integral part of the courses given by the VUSEC group, and unfortunately those are difficult to do remotely without the course infrastructure.

The Binary and Malware Analysis course that you mentioned builds on top of the book "Practical Binary Analysis" by Dennis Andriesse, so you could grab a copy of that if you are interested.

No, but last time I checked you can be a contracted student for 1200 euro's.

If I knew what I was getting into at the time, I'd do it. I did pay for extra, but in my case it was the low Dutch rate, so for me it was 400 euro's to follow hardware security, since I already graduated.

But I can give a rough outline of what they taught. It has been years ago but here you go.

Hardware security:

* Flush/Reload

* Cache eviction

* Spectre

* Rowhammer

* Implement research paper

* Read all kinds of research papers of our choosing (just use VUSEC as your seed and you'll be good to go)

Binary & Malware Analysis:

* Using IDA Pro to find the exact assembly line where the unpacker software we had to analyze unpacked its software fully into memory. Also we had to disable GDB debug protections. Something to do with ptrace and nopping some instructions out, if I recall correctly (look, I only low level programmed in my security courses and it was years ago - I'm a bit flabbergasted I remember the rough course outlines relatively well).

* Being able to dump the unpacked binary program from memory onto disk. Understanding page alignment was rough. Because even if you got it, there were a few gotcha's. I've looked at so many hexdumps it was insane.

* Taint analysis: watching user input "taint" other variables

* Instrumenting a binary with Intel PIN

* Cracking some program with Triton. I think Triton helped to instrument your binary with the help of Intel PIN by putting certain things (like xor's) into an SMT equation or something and you had this SMT/Z3 solver thingy and then you cracked it. I don't remember got a 6 out of 10 for this assignment, had a hard time cracking the real thing.

Computer & Network Security:

* Web securtiy: think XSS, CSRF, SQLi and reflected SQLi

* Application security: see binary and malware analysis

* Network security: we had to create our own packet sniffer and we enacted a Kevin Mitnick attack (it's an old school one) where we had to spoof our IP addresses, figure out the algorithm to create TCP packet numbers - all in the blind without feedback. Kevin in '97 I believe attacked the San Diego super computer (might be wrong about the details here). He noticed that the super computer S trusted a specific computer T. So the assignment was to spoof the address of T and pretend we were sending packets from that location. I think... writing this packet sniffer was my first C program. My prof. thought I was crazy that this was my first time writing C. I was, I also had 80 hours of time and motivation per week. So that helped.

* Finding vulnerabilities in C programs. I remember: stack overflows, heap overflows and format strings bugs.

-----

For binary & malware analsys + computer & network security I highly recommend hackthebox.eu

For hardware security, I haven't seen an alternative. To be fair, I'm not looking. I like to dive deep into security for a few months out of the year and then I can't stand it for a while.

Why stop at 80286, consider going back to the ideas of iAPX432, but with modern silicon tech and the ability to spend a few million transistors here and there.

(CHERI already exists on ARM and RISC-V though.)

286 far pointers were used sparingly, to save precious memory. Now we don't have any such problem and there are still unused bits in pointers even on largest 64 bit systems that might be repurposed perhaps. With virtual memory, there are all kinds of hardware supported address mappings and translations and IOMMU already so adding more transistors isn't an issue. The issue is purely cultural as you have just shown, people can't imagine it.

I suppose a CPU that only runs Rust p-code is what the OP is dreaming about...

> Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets

That's precisely what Spectre and Meltdown were though. It's unclear whether this attack would work in modern browsers but they did reenable SharedArrayBuffer & it's unclear if the existing mitigations for Spectre/Meltdown stimy this attack.

> I personally disable all the mitigations because performance boost is actually noticeable.

Congratulations, you are probably susceptible to JS code reading crypto keys on your machine.

> Or people could just understand the scope of the issue better

Do you understand the scope of the issue? Do you know that this couldn't personally affect you in a dragnet (so, not targeted, but spread out, think opportunistic ransomware) attack?

Because this statement of yours:

> Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets.

was not true for Spectre. The original spectre paper notoriously mentions JS as an attack vector.

If you truly disable all mitigations (assuming CPU and OS allow you to do so), you will reopen that hole.

So:

> The only real way this could ever be used is if you have direct access to the computer where you can run low level code.

I'm a low level kernel engineer, and I don't know this to be true in the general case. JITs, i.e. the JavaScript ones, also generate "low level code". How do you know of this not being sufficient?

Intel is getting kicked while it is down.

> the only real fix is to recognize that you can’t isolate code running on a modern system

Does pinning VMs to hardware cores (including any SMT'd multiples) fix this particular instance? My understanding was that doing that addressed many of the modern side channel exploits.

Of course that's not ideal, but it's not too bad in an era where the core count of high end CPUs continues to creep upwards.

I meant that it's a feature that's hard to implement in a way that delivers the performance gains without creating vulnerabilities like this one.

That actually doesn't work. The evaluation of the branch condition may be at some point far away from where the privilege update is recognized and executed. There is no current state to update, it's only recognized in retrospect what the state was. And carrying along data is pricey in a CPU: the instruction pointer isn't even available because of this.

You could say we only update the predictor at retirement to solve this. But that can get a little dicy also: the retirement queue would have to track this locally and retirement frees up registers, better be sure it's not the one your jump needs to read. Doable but slightly harder than you might think.

Researchers say this is CVE-2024-45332.

INTEL-SA-01247 covers that CVE.

Microcode release 20250512 has that INTEL-SA mitigated.

https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

https://www.intel.com/content/www/us/en/security-center/advi...

On an Ubuntu 24.04.2 machine:

   dpkg -l | grep microcode

   ii  amd64-microcode 3.20231019.1ubuntu2.1 amd64 Processor microcode firmware for AMD CPUs
   ii  intel-microcode 3.20250211.0ubuntu0.24.04.1 amd64 Processor microcode firmware for Intel CPUs
   ii  iucode-tool 2.3.1-3build1 amd64 Intel processor microcode tool

You're right about gamers, but other verticals are looking bad for Intel, too.

The two areas you mention (data center, integrated OEM/mobile) are the two that are most supply chain and business-lead dependent. They center around reliable deliveries of capable products at scale, hardware certifications, IT department training, and organizational bureaucracy that Intel has had captured for a long time.

But!

Data center specifically is getting hit hard from AMD in the x86 world and ARM on the other side. AWS's move to Graviton alone represents a massive dip in Intel market share, and it's not the only game in town.

Apple is continuing to succeed in the professional workspace, and AMD's share of laptop and OEM contracts just keeps going up. Once an IT department or their chosen vendor has retooled to support non-Intel, that toothpaste is not going back into the tube - not fully, at least.

For both of these, AMD's improvement in reliability and delivery at scale will be bearing fruit for the next decade (at Intel's expense), and the mindshare, which gamers and tech sensationalism are indicators for, has already shifted the market away from an Intel-dominated world to a much more competitive one. Intel will have to truly compete in that market. Intel has stayed competitive in a price-to-performance sense by undermining their own bottom line, but that lever only has so far it can be pulled.

So I'm not super bullish on Intel, sensationalism aside. They have a ton of momentum, but will need to make use of it ASAP, and they haven't shown an ability to do that so far.

The trend toward ARM in both laptops and data centers is clear. It’s being driven by power efficiency as much as performance. The x86 guys have shown that they can make x86 fast and that CISC is really not an issue, but that takes a lot of transistors and those transistors inevitably burn power. For the same performance, x86 will always be more power hungry. And so the industry will keep moving toward ARM and RISC-V.

Arm is making huge gains though — five years ago they had less than 5%. The future of x86 is not bright.

Because there's nothing else in America

So this is where they got the pager and walkie talkie ideas from

Yes but those transistors moved to greener pastures.

Has even a single web exploit ever been found in the wild? Until then, I'm not going to worry and probably not even then.

Uncaught ReferenceError: WebAssembly is not defined

UBlock Origin with JS turned off, or NoScript. Good luck.

Yeah, he should really turn mitigations on, so that when running arbitrary code from the internet he can be subject to 9999 vulnerabilities, instead of 10,000.