When you Accidentally Compromise every CPU on Earth

it's the night of January 16th 1991 it's

been exactly 5 months and 14 days since

the start of the Gulf War you suspect

that the United States armed forces is

planning an aerial bombing campaign

against Iraq however you don't know when

they're going to initiate the operation

how can you find out the exact date

you've already tried to hack into

military systems with every traditional

Cyber attack in the book but to no avail

it turns out that there's a method to

find out without directly breaching

military systems discovered by Frank

Meeks owner of 43 Domino's pizza outlets

in the Washington DC area he knows that

Operation Desert Storm is going to

commence tomorrow on January 17th due to

the spike in late night pizza orders

from government offices you see the

night before large military operations

government officials tend to stay up all

night planning ordering in copious

amounts of pizza with Meek stating I

don't think they're sitting around

watching Redskins reruns that night

after 10: p.m. the White House ordered

55 pizzas relative to their Baseline of

five over at the Pentagon this number

surged to 101 pizzas relative to their

Baseline of three this correlation of

government pizza orders and imminent

military action was coined the pizza

index which also successfully predicted

military action ahead of time in many

other cases this is a classic example of

a side Channel attack with the pizza

orders acting as the side Channel Side

Channel attacks are based on the

observation of unintended emissions of

information certain information may be

leaked due to the fundamental way a

protocol or algorithm is implemented

rather than flaws in the design of the

protocol or algorithm itself we're soon

going to learn that even though a

program's code may be entirely safe and

bug-free this doesn't necessarily mean

that the execution of these programs is

going to be safe as the CPU could

inadvertently end up leaking information

at runtime these side channels are

everywhere spanning from the analysis of

power consumption all the way to being

able to extract your own fingerprints

just by listening to the acoustic

signatures generated by swiping on your

phone's touchcreen in this video we're

going to be diving deep covering one of

the most severe exploits in the history

of

computation Tech firms are rushing to

patch a security hold that is affecting

billions of computers and smartphones

it's caused by two major flaws in

computer chips called meltdown and

Spectre the defect could enable hackers

to steal sensitive information from

nearly every modern Computing device and

smartphone they're the worst computer

bugs in history and they could be coming

for your personal information what if

there was a way for any process running

on your entire computer without

requiring any elevated permissions or

malicious installs to have free access

to all of your systems memory both from

other applications including different

virtual machines and even from the

operating system kernel itself this

means that even the benign client side

JavaScript running within a browser tab

could have full access to all of your

computer's memory being able to recover

encryption Keys photos banking

information or anything else present in

your systems Ram this was the reality in

early 2018 when two of the most

dangerous and widespread CPU

vulnerabilities meltdown and Spectre

were discovered by researchers at Google

project zero allowing any process on any

device unrestricted access to

unauthorized memory what makes these

bugs particularly dangerous is that they

don't behave like any software bug we've

seen before as they don't rely on

exploiting any fundamental weakness or

flaws in any code these vulnerabilities

are baked into the very essence of

modern CPU technology attacking

underlying CPU

microarchitectures meltdown is a more

specific type of attack only affecting

Intel CPUs manufactured after

1995 this made it somewhat easier to fix

involving increased separation between

different memory spaces Spectre on the

other hand is much more Sinister it is a

whole class of attacks that take

advantage of something called

speculative execution and Branch

prediction which are Hardware level

features present on all modern CPUs

pervasive across all CPU manufacturers

and architectur

present in virtually every desktop

laptop server and smartphone in the

world because this is not a bug or flaw

in any software but rather a fundamental

Hardware issue it's incredibly difficult

to properly patch it the United States

computer emergency Readiness team's

recommendation was to replace your CPU

stating fully removing the vulnerability

requires replacing vulnerable CPU

Hardware in order to understand the

mechanics at the heart of Spectre we're

first going to need a foundational

understanding of how computers work

specifically their memory what does

execution on a modern computer look like

you have the CPU which is responsible

for processing data and the memory which

stores data during regular execution the

CPU will constantly be reading and

writing data to and from memory it's

going to be helpful to visualize memory

as a long sequence of boxes where each

box contains one bite of information now

this type of memory is the main system

memory also known as dam short for

dynamic Random Access Memory while it is

relatively large capacity it is very

slow to read and write from let's say

your CPU wants to load some data in from

memory this retrieval process is

incredibly slow let's say in the order

of 200 NS every single time you need to

access something in memory your CPU is

going to need to wait for the incredibly

slow main memory to respond with the

data that it wants it turns out that

there's additional layers of memory

called cache memory to make this process

faster once a particular memory location

is accessed for the first time the CPU

is going to store a copy in its cap

accessing the CPU cache is blazingly

fast achieving sub Nan speeds however

its capacity is quite small relative to

Dam the next time the same memory

location is accessed the CPU can just

get the data directly out of its cache

without needing to wait for a call to

the main memory something interesting to

note about the cache is that it's not

directly readable essentially being

transparent to the program being ran

there's no direct way to know if the

specific bite of memory you're accessing

is in cash or if it's coming from m main

memory now the cachee only speeds things

up for data that has already been

accessed from the main memory at least

once before over the regular course of

execution you're inevitably going to run

into the fact that your program is going

to need to read some data from Main

memory bottlenecking the CPU let's

visualize this with an example let's say

we have some variable meem defined in

memory and only if meem is equal to True

do we want to execute a bunch of other

instructions if meem is not already in

Cache we'll need to load it in for main

memory taking upwards of 200 NS during

this memory retrieval process the CPU is

going to be forced to sit idly by as it

waits for this slow response from memory

which is an absurd way to have a CPU

operate only after the value of mem is

retrieved from memory can the CPU start

executing the rest of the instructions

needless to say it is very inefficient

to have our CPU idle during the long

memory lookup process What if after

starting the retrieval process we could

get a head start sprinting ahead in

executing our instruction

speculatively so that we're already done

by the time you receive the value of

meem this is called speculative

execution which is an optimization

technique present in virtually every CPU

since the 1990s and it's actually one of

the reasons why modern CPUs are so fast

any time we have a branch such as this

if statement the CPU has some logic that

makes an intelligent guess about which

way the branch might go this is called a

branch prediction if the CPU thinks that

it's likely for meem to be equal to true

it can Sprint ahead and spec

speculatively execute these instructions

even before it gets its response from

memory once the lookup is finally

complete if we guessed right in meem is

indeed equal to true we just saved a lot

of time as our instructions are already

executed we can keep everything we just

did which is called a commit and resume

execution from this point on this sounds

pretty cool however we obviously need to

handle the case where we get the guess

wrong meaning that everything done

spectively needs to be fully reversible

if we guessed wrong in M was not equal

to true we would need to roll back all

of the changes that were made including

reverting all of the register values

which is called a discard here's where

things start to get interesting let's

introduce the flaw that Spectre was

exploiting it turns out that when the

branch predictor makes an incorrect

guess and we roll back all of the

changes that were made during

speculative execution the state of the

CPU cache is actually not reverted let's

make this clear the code being

spectively executed might have triggered

some data to be loaded in from Main

memory resulting in it getting cashed if

it turns out that we made a bad call and

everything needs to be rolled back the

data is actually going to remain within

the CPU cache even after the roll back

this is quite serious keeping in mind

that from the software point of view

this code was quite literally never

executed we're soon going to see that

Spectre can induce one of these roll

backs by training the cpu's branch

predictor or officially conditioning it

to make a bad call on purpose the tricky

part is going to be extracting this

information from from the cache as it

contents are not directly readable

essentially being transparent since we

know that the cach responds faster than

main memory the contents of the Cache

can be inadvertently leaked with a

timing attack measuring the amount of

time it takes to retrieve the data this

alone seems easy but to be able to do

this on unauthorized memory is going to

be quite tricky however we're soon going

to see an incredibly elegant solution to

bring data from unauthorized memory into

a part of the cpu's cache that we can

probe but I digress let's not get ahead

of ourselves

with this we now have all the

ingredients needed to understand

Spectre if you've made it this far and

you're interested in learning new skills

advancing your career in building a

comprehensive understanding of software

engineering Concepts look no further

than this video sponsor codec Crafters

with codec Crafters you learn by

building your own versions of real

Technologies such as bit torrent Docker

or even redus each project Dives deep

into a specific topic starting from

scratch to final specification in a

practical Hands-On environment the cool

thing is that all of these challenges

are available in a wide variety of

programming languages meaning that you

can learn language specific skills or

new languages entirely in a real world

environment regardless of what the

original tool is written in you can get

started with any setup as you progress

through the different stages you'll be

conveniently pushing your code for

automatic rating the whole time you'll

have access to hints code examples and

even screencasts from fellow community

members if you get stuck in addition to

this any knowledge apps will be filled

in along the way as interactive

tutorials are provided to teach you

fundamental concepts when needed you can

get started with code Crafters today by

clicking the link in the description

they're offering a free tier and a 40%

discount on their paid memberships to

viewers of this channel thanks again to

codec crafters for supporting the

channel now let's get back to

Spectre let's go ahead and set the scene

starting with our main memory the

operating system kernel is responsible

for allocating this memory to different

applications a simil thing also happens

in multi-tenanted Cloud environments as

well with the hypervisor allocating

memory to different virtual machines

instead in either case this means that

there could be adjacent parts of memory

allocated to a process that we control

and to a potential victim the operating

system is supposed to isolate the memory

spaces between different processes

ensuring that any given process

including the JavaScript running within

your browser can't access another

process's memory so how do Spectre

circumvent this enabling us to read data

from a victim process let's start by

initializing an array in the part of

memory that we control we know that we

can access the elements within our array

by indexing into whatever position that

we want to retrieve all this does under

the hood is some simple pointer

arithmetic adding together the memory

location of the start of the array and

the index in order to find the memory

location that we want let's suppose that

the part of victim memory that we're

trying to read from contains the number

six but of course our code doesn't know

this what if we try to index into into a

position so high that we went out of

bounds in read from victim memory let's

call this array of x if you tried to do

this the operating system is going to

notice that we're trying to access

unauthorized memory deeming this an

illegal operation triggering a fault

preventing us from accessing the data

now what if we Instead try to do this

operation speculatively this is going to

be interesting so we want to index into

our array at position X but how can we

force this operation to be done

spectively we're going to need to add

some sort of Branch beforehand let's go

ahead and add a simple bouns check

making sure that X is within the bounds

of the array before proceeding simple

what we're going to do now is we're

actually going to train the cpu's branch

predictor conditioning it to determine

that it is likely for X to be in bounds

we can do this by making repeated calls

to this function handing it values of X

that are always in bounds if it keeps on

saying that X tends to be in bounds it

is going to become conditioned to

speculatively execute the body of the if

statement since there's a very high

chance that the bounce check will pass

based off its previous interactions

there's malicious intent here as once

the CPU has been trained we can hand it

a value of x that is purposefully out of

bounds and our CPU will happily Speed

Ahead speculatively executing the

instruction so how is this handled the

CPU is going to index into array of X

however it won't know that it's out of

bounds yet if this were to actually be

ran the colonel would kill the process

but the specul cative execution engine

just looks ahead and reads the number

six from victim memory the operating

system won't actually check if it's

accessing an illegal memory location

until later this is a crucial Nuance to

understand as a result data from victim

memory was indeed accessed this is very

interesting but once the CPU realizes

that it's gone the wrong way it's going

to roll back all of the erroneous work

that it's done even though illegal

memory has been accessed its contents

will be forgotten we need to find a way

to retain it after the roll back if it

can't be retained then all of this was

for nothing bear with me on this we're

actually going to define a second larger

array to capture this information akin

to Casting a large net let's modify our

code slightly to index into capture of

array of X when array of X is evaluated

to the number six capture of six is now

going to be accessed this is the crucial

part of the attack because we just read

from the capture array at index X6 this

memory location is going to be put into

the cache after the roll back as we now

know the cach is going to remain intact

think about that we never directly stole

the data from victim memory we just

brought an element of our own array into

cache at the index number that

corresponded to the data that we wanted

to steal it's quite an elegant trick

don't forget that the cash itself is

still not accessible to us the last step

is going to be a timing attack which is

a specific type type of side Channel

attack that's going to try and deduce

the data contained within the cache by

taking advantage of the timing

differences between cash in main memory

we can go ahead and access each and

every element of our capture array

timing how long it takes to retrieve

each element we're going to get a

sequence of slow 200 nond cache misses

until finally we get a near instant

cache hit since we found our cache hit

on array element 6 we know that the data

contained within the victim memory was

the number six it's quite a beautiful

attack Spectre comes in many different

variations what I just outlined was a

highly simplified version of Spectre

variant 1 although they all rely on the

same idea getting the CPU to spectively

run some code that illegally accesses

memory and then exfiltrating said memory

using a timing side channel on the CPU

cache if you're interested in more

vulnerability breakdowns check out these

videos and subscribe to the channel for

more content thanks for watching