How The RIDL CPU Vulnerability Was Found

[@sirmcx]

While I might be a bit biased, I really have to say that this video turned out extremely nice! Great job explaining this in a very easy to follow way!

[@hikingpete]

I love how a negative result was so pivotal.

[@nicholas7032]

I discovered this channel 5 years ago, thanks to the reverse engineering playlist. I took CS in Uni 3 years ago, inspired by this channel. Some months ago i started writing my thesis on the formalization of relaxed memory models and their speculative behaviour, and today this video is uploaded. What a journey, Live :)

[@francescomazzucco6264]

Congrats and good luck with the thesis man. I know how you feel, I finally decided what master I want to do thanks to this channel and got also inspired to take CS

[@nicholas7032]

@@naxneedssomeprivacy You can find a playlist right in this channel.

[@ndm13]

I really respect Intel for not only taking silicon vulnerabilities so seriously, not only starting a bug bounty program, but sponsoring people to promote it by analyzing existing bugs. This is dedication, and I really hope we see more companies treat security in this way. I've seen more and more companies start bug bounty programs recently, and it's definitely a move in the right direction.

[@MikaelIsaksson]

The reason they make this is to make sure no one else finds their backdoor like they did on the celeron.

[@DanKaschel]

@@MikaelIsaksson that... Doesn't make any sense

[@MikaelIsaksson]

@@DanKaschel sure it does. Now they can have a bunch of really smart people trying to find it. If they don't, great. Now we can feel like bit more sure it won't be found in the wild. If they do, oops, a "vulnerability" better fix it. To be clear, it's really hypocritical from them to care about hardware vulnerabilities when they have put them in on purpose in the past. If you didn't know they crammed in a small operating system in the CPU that could be accessed from user level by calling secret opcodes, elevating following commands to above ring 0. Basically a hardware trojan.

[@PaulG.369]

​@@MikaelIsaksson Did they become self conscious and stop doing that in newer generations of cups, or do they more effort into hiding the hw trojans better?

[@squelchedotter]

Your comment about the page size isn't quite correct: A modern x86 CPU fetches and writes 64 byte chunks of memory (the cache line size). The 4096 byte page size refers to the minimum chunk of memory that can be virtually addressed, i.e. mapped from virtual to physical memory. So basically, as you're watching replace "page" with "cache line" in most of this video. Page size only becomes relevant later when it comes to memory access controls.

[@TheAirr13]

Also, when accessing a virtual address, the processor places the virtual page number and the corresponding physical frame number in tlb for faster lookup, which also speeds up data access.

[@TitusSc]

@@TheAirr13 and to ensure that no process can access the virtual memory of other processes, each entry in the TLB is tagged with its corresponding process ID, which is what Sebastian was talking in the video, wondering if the tag check can be circumvented.

[@DontDoubtOurServers]

Also 1’or1’ doesn’t always = 1

[@bschlueter]

These aren't Linux process IDs. The hardware functionality is called PCID. There exist only 4096 different ones. Linux uses effectively only 6 (+ the upper bits for meltdown mitigation). So whenever a new thread is scheduled the TLB doesn't have to be flushed all the time. And to my knowledge the check cannot be circumvented. I did some experiments and wasn't successful

[@bschlueter]

@DNA I am not a Linux kernel engineer but to my understanding you are right. The PCID stuff is necessary to mitigate a TLB flush everytime a process switches between Kernel and userspace. Each process has a part which is running in userspace and a part which is running in kernelspace. PCID increases the switching speed. I remember I read that a few months ago but I did not understand it fully yet. But from within the kernel you can leak everything.

[@wrathofainz]

4:12 I don't know if anybody has said this yet, there are only 243 comments right now, but: What you pronounced as "fourty-two'th" should be "fourty-second" . In general: good job. Your work is appreciated.

[@peglothefirst]

I never had someone explain branch prediction so well to me. Thank lord.

[@vaisakh_km]

🙂 yes

[@nulano]

This video doesn't really talk about branch prediction, but rather only speculative execution. Branch prediction is only concerned with conditional jumps like JNZ (jump if not zero). It is a function in the CPU looking for patterns in whether a certain conditional jump is taken or not and tells the CPU which branch to load into the pipeline (for older CPUs, before speculative execution) or which branch to speculatively execute (for modern CPUs). Note that some CPUs may speculatively execute both branches (jump taken as well as not taken), the branch predictor would merely tell the CPU which branch to prefer when neither branch is stalled (waiting for memory or slow computation result).

[@llmnr3xp0sed]

This is one of the best video's you've posted. Well done!

[@miroslavmajer5155]

waaaaaaaau, I always wanna understand that issue and you just explained it briliantly! I salute you, man!

[@0x42NaN]

shoutout to intel for sponsoring this, lol! amazing video as always

[@kampet3438]

What a great timing of that upload hence I just read about them but didnt know how you would discover something like this

[@official-root]

Always awesome content @liveoverflow!

[@MADhatter_AIM]

Holy smokes, i was waiting on this one ! Big Thanks.

[@francescoventurini8605]

I made my Bachelor's thesis about RIDL, it was awesome! 😍 I basically used it to leak the hash of the root password of my Professor 's PC remotely through ssh. Cool video, thank you !

[@ibonitog]

Amazing video! I hope we get more content on hardware-type vulnerabilities and “hacking”!

[@RepublikSivizien]

You actually show out-of-order-execution (; ) vulnerabilities, like meltdown. Speculative execution (foo: xor rax, rax; jnz bar; jmp foo; bar: ) vulnerabilities like spectre are slightly different concepts. The first class is afaik intel-only, the second class is an issue for other modern CPUs of other ISAs too.

[@RepublikSivizien]

@DNA Cortex-A75 and IBMs Power microarchitecture seem to be also affected…but basically all modern (till 2019 I guess) Intel CPUs, so, this is basically a Intel-issue. the IMHO more useful speculative execution vulnerability, which can be triggered without a signal handler and therefore could not be mitigated by the kernel that simple and can also be done in non-native code like javascript, also affects a lot of other CPUs.

[@PS-bp4ju]

@@RepublikSivizien Meltdown is far not Intel only. Btw, "signal handler" can be avoided by self-modifying code, like changing nops into jmp right before transient instructions. Have never heard about this method before but it was also worked.

[@RepublikSivizien]

@@PS-bp4ju: That is spectre, not meltdown. You might have luck with the illegal out-of-order instruction in a thread. It should be possible that an illegal instruction in a child does not kill the parent, but it must be on the same core due to cache, iirc.

[@vimatefr]

Amazing video to start digging CPU vulnerabilities!

[@kevinwydler4405]

Big props to you and intel for doing this!

[@mikaay4269]

42 TOOTH lmao. These things just make my day. Thank you!

[@kh0kh0]

Amazing video! You interested me in security years ago and at finally ended up on DEFCON CTF. Might bait me into CPU bugs now...

[@warker_de]

This video is just pure Gold. Thx

[@RoiEXLab]

Very interesting topic. I must admit I didn't understand 100% of everything but it definitely gave a nice insight into the topic.

[@dandymcgee]

If anyone else wants more videos like this to watch, Christopher Domas' Defcon talks on x86 architecture are extremely fascinating.

[@locusf2]

The dude probably has the Intel architecture documents as light bedside reading lol. He did write "reductio ad absurdum" which is a program with 13 lines of x64 assembly and is turing complete.

[@AjayKumar-fd9mv]

I did not understand much of the video but still find it intresting

[@logiciananimal]

In my view, every field should have journals of negative results. I had no idea that the history of the speculative execution vulnerabilities was so rich.

[@DanKaschel]

I mean, they do. Scientific journals very frequently publish negative results.

[@CosmodiumCS]

This was awesome! Been grinding through your binary exploitation playlist. Keep it up🔥

[@nikoshalk]

Awesome video! A difficult topic but very well explained and broken down to smaller pieces!

[@kiyotaka31337]

The research was 🤯, think time to start exploring micro architecture

[@dandymcgee]

Super interesting, thanks for sharing and the great editing/research. Love your channel, huge fan!

[@walterdebruijn7046]

Thank you for this high quality content!

[@aayushgore4245]

nice video! very informative and relatable

[@henriquematias1986]

Very nice video! I wish I understood 100% of it!

[@annorome]

Really was looking for it. So nice, that Intel actually contacted you, since they reacted quite "salty" to the doings of one of my lecturers (whom I admire, you might know him: Michael Schwarz). Really really cool video! :) He tought us about fencing etc. and the simplicity of analyzing the "performance" via plotting a histogram. No big ML needed here. :D I don't know, but the segfault handler seems either like a really useful feature or as if you shot yourself in the foot. xD

[@tur7le254]

this reminded me of Chris Domas on his research on the x86 instruction set. loved his defcon talks

[@sarunint]

"The forty-twoth page" really gets me. Forty-second.

[@lohphat]

Fourty-tooth. I looked it up. English is still weird about number names, where the 1st, 2nd, and 3rd numbers in each group of 10 starting at 20 have separate names -- but at least it ain't French or Danish! 21: twenty-first (21st) note ...th 22: twenty-second (22nd) note ...nd 23: twenty-third (23rd) note ...rd 24: twenty-fourth (24th) note ...th 25: twenty-fifth (25th) note...th etc. Same for 31, 32, 33, ... 41, 42, 43... etc. I'm also a German and French speaker so I can relate -- I ALWAYS forget that 81 and 91 in French DOESN'T use the "-et-" before the "un" or "onze" but it does in 21, 31, 41, 51, 61, 71 ("...et-onze") -- but not 81 and 91 as they are "too long" for adding the "-et-". GAHHHHH!!!!

[@angryman9333]

High quality content fr

[@petersteinmeier8446]

Great Work ❤️

[@gagnon124]

great video! very educational

[@gameglitcher]

In reality bug bounties are the most cost effective way to handle security related topics, as you find the people who are very vested in the topic spending countless hours that you don't have to pay for. Then just pay for the result. I am surprised it took them so long to find someone that figured that out O_o

[@nicof_2000]

Amazing video

[@mr_moonie]

great video man the fact that intel sponsored the video is crazy haha

[@dr.humorous447]

This is fascinating 👏 This is a very great video and in depth explanation. I love your channel 😃 keep it up sir

[@puddleglum5610]

This shows the importance of publishing negative results! In some areas of research, negative results never see the light of day because they have a much smaller chance of getting accepted into journals. I think this needs to change!

[@leotm2818]

This again is a great showcase of the outstanding cyber security research going on in germany! No matter whether its the CISPA in Saarbrücken or the HGI in Bochum. Developing CPU attacks? Standardizing the new post-quantum cryptography schemes? Germany takes a major role there! Of course our neighbours from the netherlands and other universities are also very good;)

[@tete0148]

What a great video !

[@jaspermeggitt9934]

Have you considered doing more general overviews/tutorials related to programming oriented towards a more professional audience? While I love computer science, your channel is one of the very few that has managed to keep me interested. Of the programming channels I have tried watching, most are either lengthy tutorials for complete beginners or short overviews of frameworks/libraries. I wish there was a place I could find programming deep dives on more advanced/novel concepts while assuming some industry experience from the viewer.

[@hellopleychess3190]

maybe the interest is a "you-problem"

[@anthrax3404]

This is more of a defcon-style approach, which the general hacker community has. I'm sure if you want a more professional-audience catered style, you could look at Def Con or BlackHat conference talks. If you're looking for much different I'll tell you now that most of the audience does not want that.

[@modrobert]

There is a talk/video from 33C3 back in 2016 titled "What could possibly go wrong with (insert x86 instruction here)?" which goes through the CPU cache side-channel attacks.

[@0xROI]

love for your super explanation.

[@niewazneniewazne1890]

Thread is a kernel side term for process, to be specific thread whose id is the same as the thread group id is a process, while thread whose id belongs to a different thread group id is a thread in the userspace sense.

[@richardleandro8694]

Awesome!!!

[@tobiasfellmann7692]

I was at eurobsdcon in 2017, and someone modified the kernel to exit instead of throwing an segfault. I didn't understand at the moment, but now i think this could mitigate this bug. Maybe we rely to much on bugy code that segfaults are not handled critical enough..

[@codefast93]

Amazing!!!

[@MatrzakEdits]

Anyone knows what's that IDE theme (2:50)? Looks nice

[@j3r3miasmg]

I believe that in the accidental discovery, you need to guarantee that you are running both process in the same core... P.S.: It's curious how the video approaches RIDL without the necessity of talk about Meltdown.. time really goes fast... Thanks for the video.

[@InDieTasten]

4:10 42th? :DDDD I think you meant 42nd?

[@abdirakhman]

Did I understand correctly? The parent code will try to make read on secret value, which is same address on both processes, and speculative execution will run it. The speculative execution will run with actual secret value, and then it will learn that it made error because the secret's value in parent process is nullptr. Then it will trigger exception. And then we can't simply check which page table is loaded very fast.

[@melvin6228]

VUSEC gives great courses by the way! They teach it at the Vrije Universiteit Amsterdam In the courses I took we got to reproduce one of their papers actually. I reproduced GLitch :)

[@amyshaw893]

bit of a random question, but what kind of shop would I find club mate in? is it just any old supermarket, or do i have to go to a special mate shop? (assuming im already in germany)

[@felixe2890]

You can find Club Mate in a lot of normal supermarkets, e.g. REWE or Edeka, but your best chances are in beverage markets, where there might also be other types of Mate (e.g. Mio Mio) or other lesser known types of beverages.

[@amyshaw893]

@@felixe2890 thanks!

[@niewazneniewazne1890]

Yes cpu pipelining has been here for ages(Motorola 68040 from 1990 was pipelined, 386 and 486 definietly was pipelined). Out of Order Execution goes back to pentium pro(pentium 2). I somehow expected superscalar to be mentioned as that came before Out of Order Execution, but I see how it wasn't super relevant to the video.

[@St0RM33]

Intel: Bounties are too expensive, we need to hire a hacker on the cheap... 😂🤣

[@dexterman6361]

Where can I find the code you show in the video at 18:30?

[@TheBackyardChemist]

Could you maybe look into the USB-JTAG vulnerability on older Intel CPUs?

[@wChris_]

Interestingly enough in 2017 i watched the Computer Scienece CrashCourse Videos and when they mentioned caches and pipelining i thought of if you could measure the cache access time of forbidden variables. But i brushed it off, thinking that when the CPU miss predicts it would also flush the cache.

[@nukfauxsho]

Spectre and Meltdown really changed the way we look at malware

[@JaseTheAussie]

Thanks for explaining, you have such great energy

[@navneeetraj]

What a great video

[@avi12]

4:13 "Forty-second", not "Forty-tooth"

[@yash1152]

2:04 compiler explorer is everywhere

[@eduardschreder1623]

What was the "small mistake" the initial blog/paper missed in exploiting leaking kernel memory?

[@MeriaDuck]

I love this category of vulnerabilities. They are so crazy complex, yet knowing how and why they work is very satisfying. Please do more of these and a bit less Minecraft 😍

[@JeanQPublique]

Meh, I'm of the opinion that it's not up to us, the viewers, to tell the creators what to work on and not to work on. I like the minecraft stuff. And I like this stuff. For all I know all this interesting content is only able to be produced because it's fulfilling to the creator. And as soon as I start imposing my own will on it it becomes less fulfilling and goes to hell. TL;DR; Leave the creative decisions to the creators.

[@4cps777]

@@JeanQPublique I like Minecraft, spend probably way too much time playing it and at least 3/4 of all the code I've ever written is MC related, but the Minecraft series is pretty boring. It's mostly just things that most people who are interested in Minecraft already know or basic coding/hacking concepts.

[@JeanQPublique]

@@4cps777 And that's fine if you feel that way. Just like it's fine that others feel different. I think we agree, though, that overall the channel is really good. And hopefully we both agree that that's a result of creative decisions that extend beyond our personal preferences.

[@Verrisin]

11:42 how could I get a kernel address? doesn't my process use virtual memory? I should not be able to address kernel pages at all... ?

[@Verrisin]

EDIT: ok, if it's just another user process, it's not weird. But reading kernel memory still eludes me.

[@AgressiveHouse]

How would the speculative execution behave if one instruction *will* change the opcode of one of the next instructions? I know it's not the usual case for the executable code to change the next executable instructions, but it's still possible to do this, right?

[@TheSensationalMr.Science]

with those steps of: 1. prepare weird payload (something known that shouldn't work) 2. use it 3. measure seems awfully like how people use cheatengine.... interesting. Hope you have a great day & Safe Travels!

[@DeadKaspar]

Can you tell from where your intro music / medley is from or who prdocued it? Cheers!

[@pabloescobanjo2037]

Isn't the release of failed results (15:34) contradicting guidelines for ethical disclosure of vulnerabilities? I mean, the bad guys might already have managed to use these informations to figure out the remaining piece of the puzzle before researchers did and whence also before intel would have the opportunity to fix it? So, refering to some other comments I read: I agree that sharing negative results is a good idea, but just from the scientific perspective! Taking into account the above mentioned negative side-effects, this may be a bad idea for IT-Security. What do you think?

[@aniksamiurrahman6365]

Mind blown! Where can I learn more about such things?

[@LiveOverflow]

subscribe :P

[@aniksamiurrahman6365]

@@LiveOverflow Thanks, I'm a subscriber for quite a while now. Anyway, any reading material? U don't need to name any book/manual, just tell me what to look for.

[@MMrz]

4:12 I'm sorry but the forty twoth (?) is triggering me so much . . . nonono, forty second (!) :(

[@int4_t]

Cool!

[@crashowerride]

Probably meant 42nd as in forty second instead of 42th? :)

[@thomas_w]

I would like a video on what microcode is and how it can fix these problems.

[@nobodynoone2500]

Now do the TPU and the baked in "Management" ROMS. ;-)

[@alejandroalzatesanchez]

when the sponsor wants them to talk bad about him, that's wild!

[@SoloByteStudio]

"42th page" was kinda painful

[@DM-qm5sc]

We are crowd sourcing practically for free the work that intel should be doing their self.

[@iamvinku]

To be fair, it did take collaboration between several security researchers to find this class of bugs. I don't know if Intel is to blame here when it seems this could affect any type of processor of any architecture.

[@tomaspecl1082]

@D M except intel has the source code (VHDL or Verilog) for the circuitry. They could analyse it much easier.

[@OtakuSanel]

the reality is intel couldn't hire enough people to find these kind of bugs. The best situation is having countless people trying to exploit the systems and having a meaningful reward for finding them so that they can then be fixed. This is true of all companies not just intel. bug bounties are great as they are open to everyone who wants to give it a try they just need to have good enough rewards to make them be worth turning in over the black market.

[@smyaknti]

Then intel would just end up with all the people working security research (hardware and software) and keep going on in that loop. There is something called a product development cycle and there are a lot of additional new things being researched on. No one writes bug free code, its how they approach their mistakes and fixes makes them better. Plus this is a global scale research and thats how all bug bounties work.

[@slicer95]

@@tomaspecl1082 The issue comes not from the source code for the circuitry. It comes from architecture, and this is a hard topic to reason about till the field exploded in 2018.

[@rafaellisboa8493]

Thanks for this very good and interesting video! I personally like these low level / computer architecture videos a lot more.

[@JohnMillerTheThird]

4:12 forty 🦷

[@rozbrajaczpoziomow]

Shouldn't 42th be 42nd?

[@Tidwillshare]

21:55 is this him rocking Grado cans with shipibo pads???

[@supportic]

15:33 this is what students are supposed to do when writing their thesis :)

[@strangecat6082]

I feel like a 10x hardware hacker now!!!🤪

[@iamvinku]

Isn't it fun seeing the wheels turn inside the minds of incredibly intelligent people?

[@ameer2942]

18:40 "I hope this code looks familiar" Me who only used nested loops for printing stars

[@Luix]

the cpu instruction multiverse

[@sobertillnoon]

I'm shocked this is the thumbnail that won the poll

[@fghsgh]

If checking cache access times after an invalid access is how you have to exploit any of these, can't you just have the kernel flush the cache completely before it calls the sigsegv handler?

[@RepublikSivizien]

This might mitigate out-of-order-execution vulnerabilities like meltdown, but not speculative-execution vulnerabilities like spectre. In the latter, there are no segfaults.

[@seanvinsick]

A thread is an actual code being executed. A process is the container that has addressing and other process data including the thread. A thread is executed not a process.

okay! i new challenge for you (I don't know how to do it). How to get firmware(bootloader+os+app) from an embedded system (from device not from url). I don't know where uart and jtag interfaces on the device and there might be some flush mechanisms or read-write protection which i don't know.

[@marksmod]

so can this be automated?

[@mindasb]

42nd, not 42th . Great video though.

[@gautamkumar-li7ey]

Amazing video... name should be How to find new class of vulnerabilities 😅