Spectre attack explained like you're five

[@joshhefner7589]

You did a great job with this. Very clear and concise! I can't wait for your video on MeltDown.

[@JadJoubran]

Awesome :D That will be my next video!

[@AlKhawarizmi2]

This is the best explanation of Spectre that i've seen, thank you :)

[@JadJoubran]

I'm glad to hear that! Meltdown video coming either on Saturday or Monday 🎬

[@Addictivemeh]

Great explanation, I thought I understood the method before but didn't understand how they determined the values from timing. The difference in execution between reading from memory and reading from cache makes so much sense, thanks!

[@zairoxs]

I had seen this video in January when I was just curious about the issue, but I now need to understand it for a school assignment. I spend 5 hours looking at confusing explanations from other people and the whole time I said "if I could only find that one video that actually made sense" Well, I did!! Thank you! This one I understood

[@FRZmations]

Couldn't help but laugh when I saw the final clip of that hacker in a hoodie "hacking". Such an accurate representation I am left speechless

[@JadJoubran]

haha indeed

[@Microcontrollerslab]

No process can access memory address outside its memory space because each process has a page table in memory which contains both process space and kernel space. This process can not event access kernel space of its own page table. If it do so, operating system will generate an exception which will surely kill the process so how it is possible to read address of from other unprivileged memory space. If you are taking about reading from process own memory space then what is use of spectre?

[@Microcontrollerslab]

one more thing memory privileged level are already define and user application has lowest privileged level so how it is possible ? Can you please explain it?

[@longle3928]

I think it is because the instruction was speculative. If the code was put outside of the if block then an exception would be generated. But because it is put inside the if block, the hardware silently performed the operation without the OS being aware of it.

[@Microcontrollerslab]

@@longle3928 yes you are right

[@SubinPT]

You made it super simple. Thank you

[@chrisdoe2267]

+1 for the hacker hoodie

[@JadJoubran]

I'm wearing one as we speak!

[@chrisdoe2267]

who isn't :p

[@JadJoubran]

Muggles! Or non-hackers 😂

[@a.yashwanth]

If you don't know secret how is it possible to find chars[secret] takes 60ms?

[@amirsalararyakia1869]

What is the timing attack he uses to recover 'secret'?

[@Goonzilla1102]

great video, like the heartbleed one which you made. but 1 question comes up to my mind, how can the attacker know the correct precedence of the data in the cpu cache which he wants to read? with your example of "private"" mapped to "1000-1006" how would he know that "p" should be at "1000" and not "r" or "i"? would there still in such a cpu-read from 1000 compared to position 1001 be a microsecond of a difference on how fast the cpu would have read it?

[@lowprofile2120]

how are you attacked specifically though? i understand spectre, but in terms of my PC being vulnerable for attack specifically how am i found by the attacker? just by being on the internet?

[@theforgot3n1]

Very good question. I'm wondering the same. This implies the attacker has to somehow make the victim run their code on their computer. Maybe a malware can do that.

[@superdanyal2009]

It's just precision timing. Most browsers have updated javascript limiting the ability of precise timing making it almost impossible to be attacked through it, it's not completely immune of course. The attack seems complicated but is overall very impractical as a standalone vulnerability (because it's slow, depends on the variant of the spectre as well). Because timing is critical here. However if you're doing cloud computing or a provider it's considered a severe threat. Honestly in real time you are more prone to rowhammer attacks then spectre ones. There's so many other doorways for hackers, hell even microarchitectural data sampling is an exploit for processor's that are specifically hyper threaded. If you're a diligent user on your own, you don't need to worry about it.

[@lohphat]

What you didn’t explain was how the cache architecture associates chars[secret] with chars[15]. You also have to explain CPU cache associativity en.m.wikipedia.org/wiki/CPU_cache#Associativity There’s not a one to one map of main memory values in moderns CPUs. If two different memory addresses contain the same value then the cache index points to the same cache entry. That’s how the exploit works. This sharing of values. If the cache didn’t share values then this exploit wouldn’t work. I’ve been explaining it to others from that perspective, all the rest of the iterative array poking part of the explanation is secondary.

[@JadJoubran]

Thanks for the addition! Indeed, I had to omit a lot of details in order to keep it short and easy to understand

[@ElectricityTaster]

Good luck looking through the 85 tabs I currently have opened.

[@mursie100]

What do you mean by "chars[secret]". If the value of secret in your example is 'p', what does "chars['p']" even mean ?!!

[@Jackisaboss1208]

Because of how computers store character information every letter has a numeric equivalent. For example, the character 'p' is equivalent to 112. So chars[p] would give us the 112th element in the character array. We use what's called an ASCII table to convert numeric representations to characters.

[@NickKostalas]

Great video, thanks for posting! I'm curious: for Spectre exploits, can the attacker ever just read the secret data straight from the cache? Or does it always have to be done by indirect methods like you described? And is/was it any different for Meltdown?

[@jordankolbert]

Can you explain what you mean at 2:14 when you say "using this information, the attacker would read the value of chars[secret]" is secret the adress there?

[@JadJoubran]

secret is the value that you're trying to read (but is normally protected by the CPU) We trick the CPU by reading chars of secret (chars[secret]) so you're using that secret value to read one element of the array

[@jordankolbert]

Jad Joubran but how can you read chars[secret]? Wouldn't you need to know secret to read secret? Also thanks for the video!

[@JadJoubran]

Not in this case because this is happening under speculative execution, you're not supposed to be able to run this code but the CPU is running it in order to speed up execution, but by the time it realizes that the speculative execution is wrong, the value of secret has already been saved in the CPU Cache The other half of the video that you referred to, tries to recover that value from the CPU Cache

[@jordankolbert]

But isn't the cache read happening after the speculative execution when secret has been leaked to the cache? How is this code still running under speculative execution? Thanks for your help!

[@jordankolbert]

I guess I don't understand how it detects the change in cache state, and how it can derive the value of secret in a manner as to be able to read chars[secret]

[@a2zuser1]

it was very easily explained thanks i want to read more on spectre and meltdown please provide links reading materials

[@harshitgupta3386]

Won't virtual memory prevent this from happening?

[@riddler112]

whats the difference between specter and meltdown vulnerability?....even tho i saw both the video they seem the same.

[@JadJoubran]

Interested in learning Programming, JavaScript or React? Checkout my interactive online courses: - Learn Programming (for beginners) learnprogramming.online? - Learn JavaScript: learnjavascript.online? - React Tutorial: react-tutorial.app?

[@ondrej8018]

So simplified that it does not make sense in the end

[@justalonelypoteto]

(more digestible explanation at the bottom) admittedly it is quite confusing unless you already understand meltdown, but all that's happening is we're ensuring a large chunk of memory is not cached. Then, in a conditional branch which will turn out to be missed but the CPU's predictor thinks otherwise, will begin to be executed. In there, we will take the memory address to this chunk of un-cached stuff and attempt to add to it a value, this value being something we want to exfiltrate which we're not allowed to read. The execution unit of the CPU which received this will dispatch an order for both the memory address which we just calculated illegally, as well as the privilege check. What we're counting on is that the memory read will take place before the privilege check, resulting in the byte (whose value is unimportant) at the address (THIS IS THE IMPORTANT PART) of address + secret to be loaded into the CPU's cache. Since the branch predictor will miss (more complicated than how the guy in the video shows it but same principle), this entire branch's changes will be discarded, so our program won't be killed by the OS due to a memory access violation / SegFault. However, the kind of processor vulnerable to our attack does not remember that this memory read which it cached during the speculative execution should be of privileged access only, so we will be able to read that one byte whose address is the important part, from the cache. Now, we will take our memory address from before and start trying to read it or otherwise perform calculations with it. This will be slow, however, once we read from the MEMORY ADDRESS (address+secret) we will find it to be faster, now we know that the number we just used to offset our memory address is the same as the secret value. If you don't know C, this might be a good moment to learn the basics of it as, without any understanding of pointers and memory addresses, this might be just as confusing. As an alternative: When I say address+secret, what I mean is that I want to read the n-th byte of our RAM, where n is a number we know, address to which we added a secret we shouldn't be allowed to know. Let's imagine our malicious program requested from the OS/Kernel to receive 500 bytes for a variable, this might be, in terms of RAM, bytes number 40000 through 40499. We want to know what's written at byte 83002 but the CPU won't let us, so what we do is do something with the value stored at the byte n, where n is 40000 + VALUE OF 83002. This will read byte 83002 and add its value to 40000, then read the value at that address. Through the stuff I explained above, the CPU won't yet care that we're not allowed to know what's at 83002, so it'll happily cache the value we want to know, this value being at 40093 (the secret value here is 93). Now all we do is test address 40000, 40001 for the lenght of time to do something with it, and once we encounter 40093 and it reads faster we'll know that 93 was the secret value. This all happens because the CPU in question simply caches things, a smarter implementation would perhaps have accompanied this caching with a note saying which privilege was required to legally perform the operation that caused it.

[@arkadiprath2918]

If secret is already in cpu cache when speculative execution is done then while reading secret why would we go to memory?

[@zeztro]

The secret isn't in the cache until the assignment operation is performed. Doing the assignment 'secret = data[input]' fetches the value from memory and stores it in the cache in case it needs to be used again soon.

[@hemantahire1131]

Easy to understand..Thanks for sharing

[@chamaldesilva506]

Now I understand. Thanks!

[@lemonsh]

I have a question. As CPU Cache is basically a long array of bytes, how can an attacker know what does the data he got mean? Let's assume he actually got 1kb of data from the cache. What now? Apart from doing an ASCII convert and read this shit manually, how can he know what does that 1kb mean and from what app is it?

[@aeebeecee3737]

Question: now day we’re using virtual memory, the memory space is isolated each other, How can spectre meltdown load memory space that not belong to its? Or if is spectre meltdown must be a injection to access it, But if it is an injection that can access memory directly, why should it use the bug of speculative execution to do so? Could any one explain to me?

[@kamilziemian995]

I'm not a excerpt, but if you want, I can write what I know. I hope this is unnecessary since you already found answer to your questions.

[@codingtudou]

If the secret is already in the cpu cache, the. Why would it take 60ms to do char[secret]?

[@justalonelypoteto]

You got it jumbled up, I think. When we say chars[i], what we're saying is really (for 1-byte elements of an array, so chars or bytes) that we want "THE VALUE stored at the memory address of chars, offset by i bytes", i.e. if the array chars starts at memory address 1000, we want the value of the byte at 1000+i. We don't know secret, and even if secret is in the cache we wouldn't be allowed to access it. What's really happening is the following: -We cause a branch prediction execution -We take our big array, which should be completely off the cache, and ask the computer: "take the address of the array and add this secret value (somewhere outside of this program's allowed memory) to it, then read the resulting address". -This read will be sent off along with the privilege check, and will result in address 1000+secret value being loaded into the cache. -When the privilege check determines that this wasn't allowed / when the branch predictor notices this conditional branch (if ... code) will not take place because its condition is not met, it undoes everything that was changed, but doesn't touch the cache as 1000+secret is part of the array which belongs to our program. The value it contains we're allowed to have, but the specific address which is stored in the cache is what we shouldn't know, yet the part that undoes this illegal operation in the CPU does not know that -Importantly, most of our array at 1000+something is not loaded into the cache, but one part of it, that at address 1000+secret, is -We now perform operations with every part of the array, as in at 1000, 1001, ... and for each we measure the time it takes to do this -Once we reach (for example) 1043, it suddenly executes faster. Now we know that 1043 is the byte that the failed speculative execution from before mistakenly loaded. We now know the secret, 43. EDIT: TLDR It's not about the secret value sitting in our cache, it's that we used the secret value to calculate a memory address and this specific memory address is the only thing in the cache, so by trying every address this could've possibly resulted in until we find one which is cached, we eventually learn which memory address was cached and from this we know the secret

[@marciandmnd]

Excellent! Looking forward to more vids!

[@JadJoubran]

Meltdown video coming in the next few days!

[@WeightlessFlex]

What is “secret” when you are explaining the attack specifically. You never say what that is. Is it a memory address?

[@justalonelypoteto]

I'll explain it with meltdown, since it is more specific and I am more confident in understanding it: What we are basically doing is clearing the cache, then we do the whole tricking the branch predictor stuff and what we then do is some operation on an address that we have access to, that address being a pointer we have and offsetting it with a value we're not allowed to read. The reason this works is because, during speculative execution, the CPU will defer the privilege check, i.e. it will check if you were allowed to do this later on, because it is a rare occurrence that programs actually violate their memory space and doing it before would severely reduce performance (you'd have to do it for most instructions), and if it finds this to be the case it will just undo the operation. However, if this operation takes place before the privilege check it will result in the value at the address "pointer+secret" to have been cached, and since the cache for this exploit has no knowledge of which privilege is required to read it, our program can then just try to read all possible addresses of pointer+n until it finds one that returns quicker, meaning you've just hit this not cleaned up value and you know the byte you weren't allowed to read is n In code: pointer = malloc(...) //allocate a large chunk so we have space to work with (...) //maybe assign values to everything in base, ENSURE THE CACHE IS FLUSHED if(...) { *(pointer+secret) ... //do something that will require us to read the address of pointer offset by the secret value, which is currently not in cache } (...) //now do a timing attack on the cache until you find which address was cached The more scary thing about this was that spectre, the papers presenting more general ways to do this, found it possible to do this with JavaScript by playing around with the code to force your computer's compiler (JS is compiled locally just-in-time) to predictably make something that flushes the cache, as this is not a command available to you in JS. AFAIK the missed branch ensures your program doesn't crash because a segmentation fault (memory violation) is handled by the operating system, also I seem to remember being in a speculative branch is key to ensuring the privilege check is done late enough EDIT: I realize I might not have answered your question, it's a value that we add to our pointer. i.e. we take our address, 0x7f45bd4f, and add a number to it which we must not know and is firmly outside of our program's memory, it's a byte sitting somewhere like 0x2e4f3d47 and maybe it's the value 0x23 which, when added, gives us 0x7f45bd72. Once the CPU performs an operation (or even just prepares to do so) on this address, the specific byte at the position 0x7f45bd72 will then be loaded into cache

[@WeightlessFlex]

I graduated last year with your help, thanks bro I am now working at an aerospace company fulfilling my dreams

[@vittoriosilva1454]

Could never happen on a private network.....This vulnerability could only occur in a public cloud infrastructure ....

[@halbgefressen9768]

well somebody doesnt understand virtualization

[@vittoriosilva1454]

Yes , yes I do , there would be no reason for one self hosted virtual instance to try and break into another , owned and hosted by the same company ....And furthermore , this exploit is only "theoretical" and has never been deployed in the wild.....

[@vittoriosilva1454]

All this is because moore's law has hit a bump in the road , and hardware sales are down ...Because the only real advantage to buying a new server , is in the electric bill ...

[@xerxis301]

Burning Mac at the end of the video = instant like. :) You've also done a great job explaining Spectre attack, thank you.

[@JadJoubran]

haha awesome :D

[@elhamjemal2660]

great! simple and clear

[@JadJoubran]

Thanks! I'm glad you like it :D

[@messapatingy]

There is no mention of how "hello" fits into the introduction to the explanation at 1:03. I get lost here.

[@JadJoubran]

At 0:38 the attacker is trying to read a "data" variable that they created. Later I showcase how they're able to read other data from the memory by using Spectre attack. The "Hello" is an example of data that you have access to, but "private" comes almost right next afterwards

[@messapatingy]

@@JadJoubran "Later" and "almost almost right next afterwards" are not helping. Please explain in order. Thanks

[@messapatingy]

Just a thought in teaching.Things should be explained in an order whereby things are known in advance. If you leave people hanging, tell them.

[@fetteschimmel9396]

@@messapatingy shut your bitch ass up

[@HA-bj5ck]

Wowww!! The Goat!

[@MPK1881]

Excellent.

[@reepdaggle2410]

very hlepful man thank you.

[@JadJoubran]

I'm glad you like it! :D

[@xavier9480]

I don't understand, if you don't know what secret is how can you do chars[secret]

[@justalonelypoteto]

the last part was maybe badly explained. What we do is trick the CPU into using secret to calculate a number, we then do something with the memory address "number" and this results in that specific address ending up in cache, and this is not undone by the CPU once it realizes it wasn't supposed to execute that code. So, number = some address we know + the secret value. We now read a bunch of memory addresses and check how long it takes, once we find one that is faster we just subtract "some address we know" and we get the secret value. Maybe this is confusing if you've never learned C or something low-level like it, but you have to remember that the value stored at "number" or anywhere around the address we know is completely irrelevant, what we really care about is its position in memory because we calculated this position using the secret value that we shouldn't be allowed to see, so if we then later find out which specific memory position was the one that was cached, we can then extract the secret value from that.

[@alhamdulil-lard4577]

Perfect Video. I got nothing more to say

[@kamilziemian995]

Good video.

[@Anthonylimere]

very nice

[@JadJoubran]

😬

[@Abydos33RA]

A guy from Google with Intel that needs to sell cpus and Microsoft to sell windows

[@kaytube2542]

Thank you man (y)

[@JadJoubran]

I'm glad you like it 😍

[@sulemanhanif2687]

0:22

[@sinanyaman2007]

Awesome video, perfect explanation but change the title bro. This might be intended to be a clickbait but does the opposite

[@theforgot3n1]

No it's perfect

[@l3aIIin23]

thanks

[@Abydos33RA]

Has ever happened? :))

[@gracewood6768]

This is thesis. But. I am afraid

[@wildweasel3001]

Nope, not spectre. There is a new one 😂

[@Noone-of-your-Business]

Just half a minute in, no 5-year-old can possibly understand this. You might want to fix your title.

[@ShopperPlug]

This is just basic common sense to wipe the cpu cache with all zeros after a "particular" cpu cycle. the same shit you find in wiping ram blocks or hard drive sectors with all zeros. if the chip designers never implemented a specific machine code for the cpu to which erases the cpu cache... thats literally a lawsuit against the chip designers for never implementing such basic fucking task to wipe the stupid cpu cache. I highly doubt the chip designers never provided such basic needed machine code to do such thing. today we have an immense population of arrogant ass programmers just never put in thought to say hey maybe its a good idea to erase the cpu cache just for good practice in safety and bug error prevention. same concept as to always erase and release the heap memory space, same concept for the cpu cache but just write with all zeros or ones.

[@MaryMary-sh5ge]

Ha già colpito la mia password ufffffffffv

[@benjistokman]

This is literally incorrect

[@chuian7978]

totally understand! 3q