Explaining the Spectre and Meltdown Vulnerabilities

[@dumpsterdiverspcreclamation]

I have never seen a video on this issue explained so succinctly. Thank you

[@devcentral]

glad you enjoyed it!

[@Microcontrollerslab]

speculative execution is for branch prediction only. Not for other operations I think

[@devcentral]

Yes, during speculative execution, the processor makes guesses as to the likely outcome of branch instructions. Spectre uses branch prediction, but Meltdown does not. Here's the white paper that explains in great detail: spectreattack.com/spectre.pdf

[@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? 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?

[@devcentral]

Great question...from the abstract of the Meltdown white paper: The security of computer systems fundamentally relies on memory isolation, e.g., kernel address ranges are marked as non-accessible and are protected from user access. In this paper, we present Meltdown. Meltdown exploits side effects of out-of-order execution on modern processors to read arbitrary kernel-memory locations including personal data and passwords. Out-of-order execution is an indispensable performance feature and is present in a wide range of modern processors. The attack is independent of the operating system, and it does not rely on any software vulnerabilities. Meltdown breaks all security guarantees provided by address space isolation as well as paravirtualized environments and, thus, every security mechanism building upon this foundation. On affected systems, Meltdown enables an adversary to read memory of other processes or virtual machines in the cloud without any permissions or privileges, affecting millions of customers and virtually every user of a personal computer. For more details, here's a link to the paper itself: meltdownattack.com/meltdown.pdf

[@Microcontrollerslab]

Yes you are right. I have already got answers after reading both papers on spec and meltdown. Brilliant work. Must be a headache for intel :D

[@devcentral]

@@Microcontrollerslab A headache for Intel...for sure! :) Really appreciate your questions and comments on this...it helps when people get engaged and start good conversations around these topics...thanks again!

[@Microcontrollerslab]

@@devcentral you are welcome

[@tthtlc]

1.15: why spectre is named as is: because of its association with speculative caching. technically: one of the best explanation as compared with the rest.

[@devcentral]

thanks for the additional info on the spectre name...and i'm glad you enjoyed the video!

[@RaviKarthickSankar]

I was looking around different websites to understand the core concept of this vulnerabilities. But you made an awesome explanation! This video will make people to digger deeper to know more about this. Thank you

[@devcentral]

glad you enjoyed it!!

[@hazemzamalkawy14]

The best videos that I have watched about those vulnerabilities so far .

[@devcentral]

glad you enjoyed it!

[@mahmoudreda4694]

I have an assignment about Spectre. Can you please recommend a research paper to read about how it works and possible solutions.

[@devcentral]

Here's a great article that will hopefully help: danielmiessler.com/blog/simple-explanation-difference-meltdown-spectre/ And here's the whitepaper on the Spectre vulnerability: spectreattack.com/spectre.pdf

[@mahmoudreda4694]

@@devcentral Thx a lot

[@rayguthrie3580]

Great Video. What type of setup do you use to display writing on a board on the video? I am assuming that the image is flipped horizontally.

[@devcentral]

devcentral.f5.com/articles/lightboard-lessons-behind-the-scenes

[@DrumApe]

awesome!

[@foysoljyoty3148]

Dude It was the best explanation. Your presentation made me understand such a complex thing in only 13 minutes.

[@devcentral]

thanks! i'm glad you enjoyed it.

[@samuelvasco3962]

Very good explanation. Thank you!

[@devcentral]

glad you enjoyed it!

[@asireprimad]

Basically both merhods are possible because of shortcuts that are designed into the cpus?

[@devcentral]

that's basically true. the overall idea is that CPUs are designed to operate at optimal efficiency, so if they can do more than one thing at a time, then it speeds things up. And, if they can do certain operations "out of order" it speeds things up. But these efficiencies add an opportunity for malicious actions...

[@emmanuelpoirier4602]

Spectre: Would be great to see that from a debugger because I don’t see how an attacker can first set the x value with an arbitrary value (which means already having access to the memory content of the process to spy on), second if a wrong value is set for x then y gives info about a location in Ram which should not be known so basically enable an attacker to read any ram address which is great ;) however there is limits: you can’t access all the ram range with the address range defined by the expression array2(array(x)) What is not explained is how the attacker read the y value / ram content

[@devcentral]

great comment! here's a blog post from Daniel Miessler that explains all this in a slightly different way/format. I think it might be helpful here: danielmiessler.com/blog/simple-explanation-difference-meltdown-spectre/ hope this helps, and let us know if you have any other comments...thanks!

[@abstractapproach634]

Why f5, are you like super down with setting your BIOS to defaults? Is tty5 your favorite? (Hmmm what else does f5 do)

[@vinamramunot1399]

Awesome Video. Helped me so much! However, the question that I couldn't get answer for is (9.53): How does the processor access the protected memory out of order? Thank you for this video

[@devcentral]

Great question! The memory that is accessed is not, itself, out of order. The memory is organized the way it is supposed to be organized on the chips. However, some of the memory is supposed to be protected from normal user access while other parts of the memory are accessible to the user. The way that microprocessors are designed today allow for them to speculatively run operations "out of order" so that they can increase their processor speeds. For example, if a processor executes operations 1, 2, 3, 4, 5 in order, then it can "speculate" that the next operation will be "6" because it makes sense that operation 6 would be the next one after 5. And, most of the time, that is correct. But, attackers have found that they can send very targeted operations at a modern processor and make it think that it needs to access the protected part of the memory space on the computer when it wasn't supposed to at all. This is the nature of the Meltdown vulnerability. So, the memory itself is not out of order...rather, the operations sent to the processor are out of order and it tricks the processor into accessing protected memory. I hope this helps!!

[@vinamramunot1399]

@@devcentral Thank you so much for the response. such a concise explanation. Awesome!

[@johnweaver6297]

Thank you for sharing this information. The one thing I don't see here is identification of the level of access the attacker needs to have to the F5 in order to successfully exploit these vulnerabilities. Most "users" of the F5 aren't going to have accounts on the F5 itself and aren't going to have access to tmsh, bash, or Configuration Utility.

[@devcentral]

Great question! You are correct that most users won't have access to the F5 system in order to exploit these vulnerabilities. Here's an article with the initial response from F5 on all of this: support.f5.com/csp/article/K91229003 Here's an excerpt from the article that discusses the exact question you raised: "...[these] vulnerabilities require an attacker capable of providing and running binary code of their choosing on the BIG-IP platform. This raises a high bar for attackers attempting to target BIG-IP systems over a network and would require an additional, un-patched, user-space remote code execution vulnerability to exploit these new issues. The only administrative roles on a BIG-IP system that can execute binary code or exploitable analogs, such as JavaScript, are the Administrator and Resource Administrator roles. These users already have nearly complete access to the system and all secrets on the system not protected by hardware-based encryption."

[@madrox1989]

Most sec attacks use a chain of vulnerabilities to achieve whatever goal. So let's say you use a 3rd party application to orchestrate changes across your F5 appliances via iControl/REST. Compromising that orchestrator is goal enough, but you may as well sniff out the management credentials while you're at it too.

[@fortunetellerz222]

Are the f5s vulnerable to this, would any upgrade help mitigate the problem or do we need a hardware overhaul ?

[@devcentral]

great question! here's the F5 initial response to all of this: At this point, F5 is investigating, and we have no further information to share, but will be updating support.f5.com/csp/article/K91229003 as we know more.

[@sukorileakbatt294]

i wonder if the only computers that will glide through is the quantum computers?

[@KlipschHead281]

Quantum computers aren't built the same way so nothing to glide through.

[@desidaru91]

What role does the kernel has in these processor vulnerabilities?

[@frankschneider6156]

Application security is build upon OS security OS security is build upon CPU security (eg ring 0 and 3). You have a CPU security issue -> everything crumbles and it can't even be fixed/patched, as its hardware (The only thing you can do (and what is being done) via patches is trying to prevent the vulnerability from being exploited). So OS security (and thus the kernel) can try to prevent you from exploiting the hardware vulnerability (same with application security, eg in the case of spectre by browser manufacturers). Doesn't solve the root cause of the problem, but makes it more difficult for the attacker. The Kernel e.g prevents the kernel memory ,mapped into user space from being read by a user. Well in the Meltdown case the attacker anyhow tries to read kernel memory and fails, because the kernel prevents this but the CPU tells the attacker anyhow what the value is. You can't really separate different levels of security from each other, as , security is what results from the integration of all layers, hardware being the most fundamental basis. It's like the best lock in existence is not going to protect if you have no door, but just a hole in the wall. And the best lock and the best door together will not help you, if the window directly next to it is wide open.

[@devcentral]

The kernel memory is exploited using the Meltdown vulnerability. Here's an excerpt from the Meltdown Whitepaper ( meltdownattack.com/meltdown.pdf ) "Meltdown is a novel attack that allows overcoming memory isolation completely by providing a simple way for any user process to read the entire kernel memory of the machine it executes on, including all physical memory mapped in the kernel region..."

[@desidaru91]

Frank Schneider Thanks for the explaination brother 😊

[@desidaru91]

F5 DevCentral thankyou for clearing my doubt. 😊

[@alexanderbedrossian1485]

0:53 It's called Spectre cause it's exploiting the "speculative execution" feature........ "A ghost that can't be mitigated" lol.