[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:13.24,Default,,0000,0000,0000,,{\i1}Music{\i0}
Dialogue: 0,0:00:13.24,0:00:17.06,Default,,0000,0000,0000,,Herald Angel: We are here with a motto,\Nand the motto of this year is "Works For
Dialogue: 0,0:00:17.06,0:00:21.67,Default,,0000,0000,0000,,Me" and I think, who many people, how many\Npeople in here are programmmers? Raise\N
Dialogue: 0,0:00:21.67,0:00:28.70,Default,,0000,0000,0000,,your hands or shout or... Whoa, that's a\Nlot. Okay. So I think many of you will
Dialogue: 0,0:00:28.70,0:00:38.99,Default,,0000,0000,0000,,work on x86. Yeah. And I think you assume\Nthat it works, and that everything works
Dialogue: 0,0:00:38.99,0:00:48.15,Default,,0000,0000,0000,,as intended And I mean: What could go\Nwrong? Our next talk, the first one today,
Dialogue: 0,0:00:48.15,0:00:52.29,Default,,0000,0000,0000,,will be by Clémentine Maurice, who\Npreviously was here with RowhammerJS,
Dialogue: 0,0:00:52.29,0:01:01.74,Default,,0000,0000,0000,,something I would call scary, and Moritz\NLipp, who has worked on the Armageddon
Dialogue: 0,0:01:01.74,0:01:09.82,Default,,0000,0000,0000,,exploit, back, what is it? Okay, so the\Nnext... I would like to hear a really warm\N
Dialogue: 0,0:01:09.82,0:01:14.46,Default,,0000,0000,0000,,applause for the speakers for the talk\N"What could what could possibly go wrong
Dialogue: 0,0:01:14.46,0:01:17.28,Default,,0000,0000,0000,,with insert x86 instruction here?"
Dialogue: 0,0:01:17.28,0:01:18.38,Default,,0000,0000,0000,,thank you.
Dialogue: 0,0:01:18.38,0:01:28.29,Default,,0000,0000,0000,,{\i1}Applause{\i0}
Dialogue: 0,0:01:28.29,0:01:32.53,Default,,0000,0000,0000,,Clémentine Maurice (CM): Well, thank you\Nall for being here this morning. Yes, this
Dialogue: 0,0:01:32.53,0:01:38.08,Default,,0000,0000,0000,,is our talk "What could possibly go wrong\Nwith insert x86 instructions here". So
Dialogue: 0,0:01:38.08,0:01:42.85,Default,,0000,0000,0000,,just a few words about ourselves: So I'm\NClémentine Maurice, I got my PhD last year
Dialogue: 0,0:01:42.85,0:01:47.12,Default,,0000,0000,0000,,in computer science and I'm now working as\Na postdoc at Graz University of Technology
Dialogue: 0,0:01:47.12,0:01:52.09,Default,,0000,0000,0000,,in Austria. You can reach me on Twitter or\Nby email but there's also I think a lots
Dialogue: 0,0:01:52.09,0:01:56.67,Default,,0000,0000,0000,,of time before the Congress is over.\NMoritz Lipp (ML): Hi and my name is Moritz
Dialogue: 0,0:01:56.67,0:02:01.52,Default,,0000,0000,0000,,Lipp, I'm a PhD student at Graz University\Nof Technology and you can also reach me on
Dialogue: 0,0:02:01.52,0:02:06.68,Default,,0000,0000,0000,,Twitter or just after our talk and in the\Nnext days.
Dialogue: 0,0:02:06.68,0:02:10.86,Default,,0000,0000,0000,,CM: So, about this talk: So, the title\Nsays this is a talk about x86
Dialogue: 0,0:02:10.86,0:02:17.72,Default,,0000,0000,0000,,instructions, but this is not a talk about\Nsoftware. Don't leave yet! I'm actually
Dialogue: 0,0:02:17.72,0:02:22.44,Default,,0000,0000,0000,,even assuming safe software and the point\Nthat we want to make is that safe software
Dialogue: 0,0:02:22.44,0:02:27.39,Default,,0000,0000,0000,,does not mean safe execution and we have\Ninformation leakage because of the
Dialogue: 0,0:02:27.39,0:02:32.56,Default,,0000,0000,0000,,underlying hardware and this is what we're\Ngoing to talk about today. So we'll be
Dialogue: 0,0:02:32.56,0:02:36.82,Default,,0000,0000,0000,,talking about cache attacks, what are\Nthey, what can we do with that and also a
Dialogue: 0,0:02:36.82,0:02:41.51,Default,,0000,0000,0000,,special kind of cache attack that we found\Nthis year. So... doing cache attacks
Dialogue: 0,0:02:41.51,0:02:48.59,Default,,0000,0000,0000,,without memory accesses and how to use\Nthat even to bypass kernel ASLR.
Dialogue: 0,0:02:48.59,0:02:53.13,Default,,0000,0000,0000,,So again, the talk says is to talk about\Nx86 instructions but this is even more
Dialogue: 0,0:02:53.13,0:02:58.21,Default,,0000,0000,0000,,global than that. We can also mount these\Ncache attacks on ARM and not only on the
Dialogue: 0,0:02:58.21,0:03:07.05,Default,,0000,0000,0000,,x86. So some of the examples that you will\Nsee also applies to ARM. So today we'll do
Dialogue: 0,0:03:07.05,0:03:11.42,Default,,0000,0000,0000,,have a bit of background, but actually\Nmost of the background will be along the
Dialogue: 0,0:03:11.42,0:03:19.25,Default,,0000,0000,0000,,lines because this covers really a huge\Nchunk of our research, and we'll see
Dialogue: 0,0:03:19.25,0:03:24.21,Default,,0000,0000,0000,,mainly three instructions: So "mov" and\Nhow we can perform these cache attacks,
Dialogue: 0,0:03:24.21,0:03:29.43,Default,,0000,0000,0000,,what are they... The instruction\N"clflush", so here we'll be doing cache
Dialogue: 0,0:03:29.43,0:03:36.37,Default,,0000,0000,0000,,attacks without any memory accesses. Then\Nwe'll see "prefetch" and how we can bypass
Dialogue: 0,0:03:36.37,0:03:43.42,Default,,0000,0000,0000,,kernel ASLR and lots of translations\Nlevels, and then there's even a bonus
Dialogue: 0,0:03:43.42,0:03:48.95,Default,,0000,0000,0000,,track, so it's this this will be not our\Nworks, but even more instructions and even
Dialogue: 0,0:03:48.95,0:03:54.21,Default,,0000,0000,0000,,more text.\NOkay, so let's start with a bit of an
Dialogue: 0,0:03:54.21,0:04:01.19,Default,,0000,0000,0000,,introduction. So we will be mainly\Nfocusing on Intel CPUs, and this is
Dialogue: 0,0:04:01.19,0:04:05.60,Default,,0000,0000,0000,,roughly in terms of cores and caches, how\Nit looks like today. So we have different
Dialogue: 0,0:04:05.60,0:04:09.44,Default,,0000,0000,0000,,levels of cores ...uh... different cores\Nso here four cores, and different levels
Dialogue: 0,0:04:09.44,0:04:14.22,Default,,0000,0000,0000,,of caches. So here usually we have three\Nlevels of caches. We have level 1 and
Dialogue: 0,0:04:14.22,0:04:18.27,Default,,0000,0000,0000,,level 2 that are private to each call,\Nwhich means that core 0 can only access
Dialogue: 0,0:04:18.27,0:04:24.52,Default,,0000,0000,0000,,its level 1 and its level 2 and not level\N1 and level 2 of, for example, core 3, and
Dialogue: 0,0:04:24.52,0:04:30.13,Default,,0000,0000,0000,,we have the last level cache... so here if\Nyou can see the pointer... So this one is
Dialogue: 0,0:04:30.13,0:04:36.29,Default,,0000,0000,0000,,divided in slices so we have as many\Nslices as cores, so here 4 slices, but all
Dialogue: 0,0:04:36.29,0:04:40.66,Default,,0000,0000,0000,,the slices are shared across core so core\N0 can access the whole last level cache,
Dialogue: 0,0:04:40.66,0:04:48.67,Default,,0000,0000,0000,,that's 0 1 2 & 3. We also have a nice\Nproperty on Intel CPUs is that this level
Dialogue: 0,0:04:48.67,0:04:52.28,Default,,0000,0000,0000,,of cache is inclusive, and what it means\Nis that everything that is contained in
Dialogue: 0,0:04:52.28,0:04:56.89,Default,,0000,0000,0000,,level 1 and level 2 will also be contained\Nin the last level cache, and this will
Dialogue: 0,0:04:56.89,0:05:01.44,Default,,0000,0000,0000,,prove to be quite useful for cache\Nattacks.
Dialogue: 0,0:05:01.44,0:05:08.43,Default,,0000,0000,0000,,So today we mostly have set associative\Ncaches. What it means is that we have data
Dialogue: 0,0:05:08.43,0:05:13.25,Default,,0000,0000,0000,,that is loaded in specific sets and that\Ndepends only on its address. So we have
Dialogue: 0,0:05:13.25,0:05:18.90,Default,,0000,0000,0000,,some bits of the address that gives us the\Nindex and that says "Ok the line is going
Dialogue: 0,0:05:18.90,0:05:24.61,Default,,0000,0000,0000,,to be loaded in this cache set", so this\Nis a cache set. Then we have several ways
Dialogue: 0,0:05:24.61,0:05:30.63,Default,,0000,0000,0000,,per set so here we have 4 ways and the\Ncacheine is going to be loaded in a
Dialogue: 0,0:05:30.63,0:05:35.27,Default,,0000,0000,0000,,specific way and that will only depend on\Nthe replacement policy and not on the
Dialogue: 0,0:05:35.27,0:05:40.80,Default,,0000,0000,0000,,address itself, so when you load a line\Ninto the cache, usually the cache is
Dialogue: 0,0:05:40.80,0:05:44.83,Default,,0000,0000,0000,,already full and you have to make room for\Na new line. So this is where the
Dialogue: 0,0:05:44.83,0:05:49.73,Default,,0000,0000,0000,,replacement replacement policy—this is\Nwhat it does—it says ok I'm going to
Dialogue: 0,0:05:49.73,0:05:57.78,Default,,0000,0000,0000,,remove this line to make room for the next\Nline. So for today we're going to see only
Dialogue: 0,0:05:57.78,0:06:01.96,Default,,0000,0000,0000,,three instruction as I've been telling\Nyou. So the move instruction, it does a
Dialogue: 0,0:06:01.96,0:06:06.61,Default,,0000,0000,0000,,lot of things but the only aspect that\Nwe're interested in about it that can
Dialogue: 0,0:06:06.61,0:06:12.81,Default,,0000,0000,0000,,access data in the main memory.\NWe're going to see a clflush what it does
Dialogue: 0,0:06:12.81,0:06:18.35,Default,,0000,0000,0000,,is that it removes a cache line from the\Ncache, from the whole cache. And we're
Dialogue: 0,0:06:18.35,0:06:25.57,Default,,0000,0000,0000,,going to see prefetch, it prefetches a\Ncache line for future use. So we're going
Dialogue: 0,0:06:25.57,0:06:30.52,Default,,0000,0000,0000,,to see what they do and the kind of side\Neffects that they have and all the attacks
Dialogue: 0,0:06:30.52,0:06:34.80,Default,,0000,0000,0000,,that we can do with them. And that's\Nbasically all the example you need for
Dialogue: 0,0:06:34.80,0:06:39.83,Default,,0000,0000,0000,,today so even if you're not an expert of\Nx86 don't worry it's not just slides full
Dialogue: 0,0:06:39.83,0:06:44.90,Default,,0000,0000,0000,,of assembly and stuff. Okay so on to the\Nfirst one.
Dialogue: 0,0:06:44.90,0:06:49.94,Default,,0000,0000,0000,,ML: So we will first start with the 'mov'\Ninstruction and actually the first slide
Dialogue: 0,0:06:49.94,0:06:57.81,Default,,0000,0000,0000,,is full of code, however as you can see\Nthe mov instruction is used to move data
Dialogue: 0,0:06:57.81,0:07:02.63,Default,,0000,0000,0000,,from registers to registers, from the main\Nmemory and back to the main memory and as
Dialogue: 0,0:07:02.63,0:07:07.24,Default,,0000,0000,0000,,you can see there are many moves you can\Nuse but basically it's just to move data
Dialogue: 0,0:07:07.24,0:07:12.59,Default,,0000,0000,0000,,and that's all we need to know. In\Naddition, a lot of exceptions can occur so
Dialogue: 0,0:07:12.59,0:07:18.14,Default,,0000,0000,0000,,we can assume that those restrictions are\Nso tight that nothing can go wrong when
Dialogue: 0,0:07:18.14,0:07:22.21,Default,,0000,0000,0000,,you just move data because moving data is\Nsimple.
Dialogue: 0,0:07:22.21,0:07:27.88,Default,,0000,0000,0000,,However while there are a lot of\Nexceptions the data that is accessed is
Dialogue: 0,0:07:27.88,0:07:35.01,Default,,0000,0000,0000,,always loaded into the cache, so data is\Nin the cache and this is transparent to
Dialogue: 0,0:07:35.01,0:07:40.87,Default,,0000,0000,0000,,the program that is running. However,\Nthere are side-effects when you run these
Dialogue: 0,0:07:40.87,0:07:46.22,Default,,0000,0000,0000,,instructions, and we will see how they\Nlook like with the mov instruction. So you
Dialogue: 0,0:07:46.22,0:07:51.29,Default,,0000,0000,0000,,probably all know that data can either be\Nin CPU registers, in the different levels
Dialogue: 0,0:07:51.29,0:07:56.03,Default,,0000,0000,0000,,of the cache that Clementine showed to you\Nearlier, in the main memory, or on the
Dialogue: 0,0:07:56.03,0:08:02.22,Default,,0000,0000,0000,,disk, and depending on where the memory\Nand the data is located it needs a longer
Dialogue: 0,0:08:02.22,0:08:09.69,Default,,0000,0000,0000,,time to be loaded back to the CPU, and\Nthis is what we can see in this plot. So
Dialogue: 0,0:08:09.69,0:08:15.74,Default,,0000,0000,0000,,we try here to measure the access time of\Nan address over and over again, assuming
Dialogue: 0,0:08:15.74,0:08:21.76,Default,,0000,0000,0000,,that when we access it more often, it is\Nalready stored in the cache. So around 70
Dialogue: 0,0:08:21.76,0:08:27.29,Default,,0000,0000,0000,,cycles, most of the time we can assume\Nwhen we load an address and it takes 70
Dialogue: 0,0:08:27.29,0:08:34.81,Default,,0000,0000,0000,,cycles, it's loaded into the cache.\NHowever, when we assume that the data is
Dialogue: 0,0:08:34.81,0:08:39.66,Default,,0000,0000,0000,,loaded from the main memory, we can\Nclearly see that it needs a much longer
Dialogue: 0,0:08:39.66,0:08:46.72,Default,,0000,0000,0000,,time like a bit more than 200 cycles. So\Ndepending when we measure the time it
Dialogue: 0,0:08:46.72,0:08:51.47,Default,,0000,0000,0000,,takes to load the address we can say the\Ndata has been loaded to the cache or the
Dialogue: 0,0:08:51.47,0:08:58.34,Default,,0000,0000,0000,,data is still located in the main memory.\NAnd this property is what we can exploit
Dialogue: 0,0:08:58.34,0:09:05.34,Default,,0000,0000,0000,,using cache attacks. So we measure the\Ntiming differences on memory accesses. And
Dialogue: 0,0:09:05.34,0:09:09.94,Default,,0000,0000,0000,,what an attacker does he monitors the\Ncache lines, but he has no way to know
Dialogue: 0,0:09:09.94,0:09:14.46,Default,,0000,0000,0000,,what's actually the content of the cache\Nline. So we can only monitor that this
Dialogue: 0,0:09:14.46,0:09:20.10,Default,,0000,0000,0000,,cache line has been accessed and not\Nwhat's actually stored in the cache line.
Dialogue: 0,0:09:20.10,0:09:24.41,Default,,0000,0000,0000,,And what you can do with this is you can\Nimplement covert channels, so you can
Dialogue: 0,0:09:24.41,0:09:29.58,Default,,0000,0000,0000,,allow two processes to communicate with\Neach other evading the permission system
Dialogue: 0,0:09:29.58,0:09:35.06,Default,,0000,0000,0000,,what we will see later on. In addition you\Ncan also do side channel attacks, so you
Dialogue: 0,0:09:35.06,0:09:40.60,Default,,0000,0000,0000,,can spy with a malicious attacking\Napplication on benign processes, and you
Dialogue: 0,0:09:40.60,0:09:46.14,Default,,0000,0000,0000,,can use this to steal cryptographic keys\Nor to spy on keystrokes.
Dialogue: 0,0:09:46.14,0:09:53.65,Default,,0000,0000,0000,,And basically we have different types of\Ncache attacks and I want to explain the
Dialogue: 0,0:09:53.65,0:09:58.81,Default,,0000,0000,0000,,most popular one, the "Flush+Reload"\Nattack, in the beginning. So on the left,
Dialogue: 0,0:09:58.81,0:10:03.11,Default,,0000,0000,0000,,you have the address space of the victim,\Nand on the right you have the address
Dialogue: 0,0:10:03.11,0:10:08.56,Default,,0000,0000,0000,,space of the attacker who maps a shared\Nlibrary—an executable—that the victim is
Dialogue: 0,0:10:08.56,0:10:14.90,Default,,0000,0000,0000,,using in to its own address space, like\Nthe red rectangle. And this means that
Dialogue: 0,0:10:14.90,0:10:22.76,Default,,0000,0000,0000,,when this data is stored in the cache,\Nit's cached for both processes. Now the
Dialogue: 0,0:10:22.76,0:10:28.17,Default,,0000,0000,0000,,attacker can use the flush instruction to\Nremove the data out of the cache, so it's
Dialogue: 0,0:10:28.17,0:10:34.42,Default,,0000,0000,0000,,not in the cache anymore, so it's also not\Ncached for the victim. Now the attacker
Dialogue: 0,0:10:34.42,0:10:39.10,Default,,0000,0000,0000,,can schedule the victim and if the victim\Ndecides "yeah, I need this data", it will
Dialogue: 0,0:10:39.10,0:10:44.97,Default,,0000,0000,0000,,be loaded back into the cache. And now the\Nattacker can reload the data, measure the
Dialogue: 0,0:10:44.97,0:10:49.66,Default,,0000,0000,0000,,time how long it took, and then decide\N"okay, the victim has accessed the data in
Dialogue: 0,0:10:49.66,0:10:54.18,Default,,0000,0000,0000,,the meantime" or "the victim has not\Naccessed the data in the meantime." And by
Dialogue: 0,0:10:54.18,0:10:58.96,Default,,0000,0000,0000,,that you can spy if this address has been\Nused.
Dialogue: 0,0:10:58.96,0:11:03.24,Default,,0000,0000,0000,,The second type of attack is called\N"Prime+Probe" and it does not rely on the
Dialogue: 0,0:11:03.24,0:11:08.97,Default,,0000,0000,0000,,shared memory like the "Flush+Reload"\Nattack, and it works as following: Instead
Dialogue: 0,0:11:08.97,0:11:16.14,Default,,0000,0000,0000,,of mapping anything into its own address\Nspace, the attacker loads a lot of data
Dialogue: 0,0:11:16.14,0:11:24.59,Default,,0000,0000,0000,,into one cache line, here, and fills the\Ncache. Now he again schedules the victim
Dialogue: 0,0:11:24.59,0:11:31.82,Default,,0000,0000,0000,,and the schedule can access data that maps\Nto the same cache set.
Dialogue: 0,0:11:31.82,0:11:38.05,Default,,0000,0000,0000,,So the cache set is used by the attacker\Nand the victim at the same time. Now the
Dialogue: 0,0:11:38.05,0:11:43.05,Default,,0000,0000,0000,,attacker can start measuring the access\Ntime to the addresses he loaded into the
Dialogue: 0,0:11:43.05,0:11:49.05,Default,,0000,0000,0000,,cache before, and when he accesses an\Naddress that is still in the cache it's
Dialogue: 0,0:11:49.05,0:11:55.65,Default,,0000,0000,0000,,faster so he measures the lower time. And\Nif it's not in the cache anymore it has to
Dialogue: 0,0:11:55.65,0:12:01.28,Default,,0000,0000,0000,,be reloaded into the cache so it takes a\Nlonger time. He can sum this up and detect
Dialogue: 0,0:12:01.28,0:12:07.87,Default,,0000,0000,0000,,if the victim has loaded data into the\Ncache as well. So the first thing we want
Dialogue: 0,0:12:07.87,0:12:11.90,Default,,0000,0000,0000,,to show you is what you can do with cache\Nattacks is you can implement a covert
Dialogue: 0,0:12:11.90,0:12:17.44,Default,,0000,0000,0000,,channel and this could be happening in the\Nfollowing scenario.
Dialogue: 0,0:12:17.44,0:12:23.61,Default,,0000,0000,0000,,You install an app on your phone to view\Nyour favorite images you take, to apply
Dialogue: 0,0:12:23.61,0:12:28.63,Default,,0000,0000,0000,,some filters, and in the end you don't\Nknow that it's malicious because the only
Dialogue: 0,0:12:28.63,0:12:33.61,Default,,0000,0000,0000,,permission it requires is to access your\Nimages which makes sense. So you can
Dialogue: 0,0:12:33.61,0:12:38.70,Default,,0000,0000,0000,,easily install it without any fear. In\Naddition you want to know what the weather
Dialogue: 0,0:12:38.70,0:12:43.04,Default,,0000,0000,0000,,is outside, so you install a nice little\Nweather widget, and the only permission it
Dialogue: 0,0:12:43.04,0:12:48.23,Default,,0000,0000,0000,,has is to access the internet because it\Nhas to load the information from
Dialogue: 0,0:12:48.23,0:12:55.57,Default,,0000,0000,0000,,somewhere. So what happens if you're able\Nto implement a covert channel between two
Dialogue: 0,0:12:55.57,0:12:59.78,Default,,0000,0000,0000,,these two applications, without any\Npermissions and privileges so they can
Dialogue: 0,0:12:59.78,0:13:05.06,Default,,0000,0000,0000,,communicate with each other without using\Nany mechanisms provided by the operating
Dialogue: 0,0:13:05.06,0:13:11.15,Default,,0000,0000,0000,,system, so it's hidden. It can happen that\Nnow the gallery app can send the image to
Dialogue: 0,0:13:11.15,0:13:18.68,Default,,0000,0000,0000,,the internet, it will be uploaded and\Nexposed for everyone. So maybe you don't
Dialogue: 0,0:13:18.68,0:13:25.61,Default,,0000,0000,0000,,want to see the cat picture everywhere.\NWhile we can do this with those
Dialogue: 0,0:13:25.61,0:13:30.22,Default,,0000,0000,0000,,Prime+Probe/ Flush+Reload attacks, we will\Ndiscuss a covert channel using
Dialogue: 0,0:13:30.22,0:13:35.69,Default,,0000,0000,0000,,Prime+Probe. So how can we transmit this\Ndata? We need to transmit ones and zeros
Dialogue: 0,0:13:35.69,0:13:40.98,Default,,0000,0000,0000,,at some point. So the sender and the\Nreceiver agree on one cache set that they
Dialogue: 0,0:13:40.98,0:13:49.32,Default,,0000,0000,0000,,both use. The receiver probes the set all\Nthe time. When the sender wants to
Dialogue: 0,0:13:49.32,0:13:57.53,Default,,0000,0000,0000,,transmit a zero he just does nothing, so\Nthe lines of the receiver are in the cache
Dialogue: 0,0:13:57.53,0:14:01.81,Default,,0000,0000,0000,,all the time, and he knows "okay, he's\Nsending nothing", so it's a zero.
Dialogue: 0,0:14:01.81,0:14:05.94,Default,,0000,0000,0000,,On the other hand if the sender wants to\Ntransmit a one, he starts accessing
Dialogue: 0,0:14:05.94,0:14:10.80,Default,,0000,0000,0000,,addresses that map to the same cache set\Nso it will take a longer time for the
Dialogue: 0,0:14:10.80,0:14:16.54,Default,,0000,0000,0000,,receiver to access its addresses again,\Nand he knows "okay, the sender just sent
Dialogue: 0,0:14:16.54,0:14:23.06,Default,,0000,0000,0000,,me a one", and Clementine will show you\Nwhat you can do with this covert channel.
Dialogue: 0,0:14:23.06,0:14:25.18,Default,,0000,0000,0000,,CM: So the really nice thing about
Dialogue: 0,0:14:25.18,0:14:28.96,Default,,0000,0000,0000,,Prime+Probe is that it has really low\Nrequirements. It doesn't need any kind of
Dialogue: 0,0:14:28.96,0:14:34.35,Default,,0000,0000,0000,,shared memory. For example if you have two\Nvirtual machines you could have some
Dialogue: 0,0:14:34.35,0:14:38.70,Default,,0000,0000,0000,,shared memory via memory deduplication.\NThe thing is that this is highly insecure,
Dialogue: 0,0:14:38.70,0:14:43.97,Default,,0000,0000,0000,,so cloud providers like Amazon ec2, they\Ndisable that. Now we can still use
Dialogue: 0,0:14:43.97,0:14:50.43,Default,,0000,0000,0000,,Prime+Probe because it doesn't need this\Nshared memory. Another problem with cache
Dialogue: 0,0:14:50.43,0:14:54.100,Default,,0000,0000,0000,,covert channels is that they are quite\Nnoisy. So when you have other applications
Dialogue: 0,0:14:54.100,0:14:59.26,Default,,0000,0000,0000,,that are also running on the system, they\Nare all competing for the cache and they
Dialogue: 0,0:14:59.26,0:15:03.01,Default,,0000,0000,0000,,might, like, evict some cache lines,\Nespecially if it's an application that is
Dialogue: 0,0:15:03.01,0:15:08.75,Default,,0000,0000,0000,,very memory intensive. And you also have\Nnoise due to the fact that the sender and
Dialogue: 0,0:15:08.75,0:15:12.77,Default,,0000,0000,0000,,the receiver might not be scheduled at the\Nsame time. So if you have your sender that
Dialogue: 0,0:15:12.77,0:15:16.65,Default,,0000,0000,0000,,sends all the things and the receiver is\Nnot scheduled then some part of the
Dialogue: 0,0:15:16.65,0:15:22.54,Default,,0000,0000,0000,,transmission can get lost. So what we did\Nis we tried to build an error-free covert
Dialogue: 0,0:15:22.54,0:15:30.83,Default,,0000,0000,0000,,channel. We took care of all these noise\Nissues by using some error detection to
Dialogue: 0,0:15:30.83,0:15:36.47,Default,,0000,0000,0000,,resynchronize the sender and the receiver\Nand then we use some error correction to
Dialogue: 0,0:15:36.47,0:15:40.78,Default,,0000,0000,0000,,correct the remaining errors.\NSo we managed to have a completely error-
Dialogue: 0,0:15:40.78,0:15:46.07,Default,,0000,0000,0000,,free covert channel even if you have a lot\Nof noise, so let's say another virtual
Dialogue: 0,0:15:46.07,0:15:54.12,Default,,0000,0000,0000,,machine also on the machine serving files\Nthrough a web server, also doing lots of
Dialogue: 0,0:15:54.12,0:16:01.60,Default,,0000,0000,0000,,memory-intensive tasks at the same time,\Nand the covert channel stayed completely
Dialogue: 0,0:16:01.60,0:16:07.61,Default,,0000,0000,0000,,error-free, and around 40 to 75 kilobytes\Nper second, which is still quite a lot.
Dialogue: 0,0:16:07.61,0:16:14.47,Default,,0000,0000,0000,,All of this is between virtual machines on\NAmazon ec2. And the really neat thing—we
Dialogue: 0,0:16:14.47,0:16:19.39,Default,,0000,0000,0000,,wanted to do something with that—and\Nbasically we managed to create an SSH
Dialogue: 0,0:16:19.39,0:16:27.06,Default,,0000,0000,0000,,connection really over the cache. So they\Ndon't have any network between
Dialogue: 0,0:16:27.06,0:16:31.44,Default,,0000,0000,0000,,them, but just we are sending the zeros\Nand the ones and we have an SSH connection
Dialogue: 0,0:16:31.44,0:16:36.84,Default,,0000,0000,0000,,between them. So you could say that cache\Ncovert channels are nothing, but I think
Dialogue: 0,0:16:36.84,0:16:43.08,Default,,0000,0000,0000,,it's a real threat. And if you want to\Nhave more details about this work in
Dialogue: 0,0:16:43.08,0:16:49.22,Default,,0000,0000,0000,,particular, it will be published soon at\NNDSS.
Dialogue: 0,0:16:49.22,0:16:54.04,Default,,0000,0000,0000,,So the second application that we wanted\Nto show you is that we can attack crypto
Dialogue: 0,0:16:54.04,0:17:01.34,Default,,0000,0000,0000,,with cache attacks. In particular we are\Ngoing to show an attack on AES and a
Dialogue: 0,0:17:01.34,0:17:04.99,Default,,0000,0000,0000,,special implementation of AES that uses\NT-Tables. so that's the fast software
Dialogue: 0,0:17:04.99,0:17:11.65,Default,,0000,0000,0000,,implementation because it uses some\Nprecomputed lookup tables. It's known to
Dialogue: 0,0:17:11.65,0:17:17.49,Default,,0000,0000,0000,,be vulnerable to side-channel attacks\Nsince 2006 by Osvik et al, and it's a one-
Dialogue: 0,0:17:17.49,0:17:24.11,Default,,0000,0000,0000,,round known plaintext attack, so you have\Np—or plaintext—and k, your secret key. And
Dialogue: 0,0:17:24.11,0:17:29.57,Default,,0000,0000,0000,,the AES algorithm, what it does is compute\Nan intermediate state at each round r.
Dialogue: 0,0:17:29.57,0:17:38.56,Default,,0000,0000,0000,,And in the first round, the accessed table\Nindices are just p XOR k. Now it's a known
Dialogue: 0,0:17:38.56,0:17:43.50,Default,,0000,0000,0000,,plaintext attack, what this means is that\Nif you can recover the accessed table
Dialogue: 0,0:17:43.50,0:17:49.46,Default,,0000,0000,0000,,indices you've also managed to recover the\Nkey because it's just XOR. So that would
Dialogue: 0,0:17:49.46,0:17:55.45,Default,,0000,0000,0000,,be bad, right, if we could recover these\Naccessed table indices. Well we can, with
Dialogue: 0,0:17:55.45,0:18:00.51,Default,,0000,0000,0000,,cache attacks! So we did that with\NFlush+Reload and with Prime+Probe. On the
Dialogue: 0,0:18:00.51,0:18:05.81,Default,,0000,0000,0000,,x-axis you have the plaintext byte values\Nand on the y-axis you have the addresses
Dialogue: 0,0:18:05.81,0:18:15.53,Default,,0000,0000,0000,,which are essentially the T table entries.\NSo a black cell means that we've monitored
Dialogue: 0,0:18:15.53,0:18:19.97,Default,,0000,0000,0000,,the cache line, and we've seen a lot of\Ncache hits. So basically the blacker it
Dialogue: 0,0:18:19.97,0:18:25.65,Default,,0000,0000,0000,,is, the more certain we are that the\NT-Table entry has been accessed. And here
Dialogue: 0,0:18:25.65,0:18:31.78,Default,,0000,0000,0000,,it's a toy example, the key is all-zeros,\Nbut you would basically just have a
Dialogue: 0,0:18:31.78,0:18:35.70,Default,,0000,0000,0000,,different pattern if the key was not all-\Nzeros, and as long as you can see this
Dialogue: 0,0:18:35.70,0:18:43.41,Default,,0000,0000,0000,,nice diagonal or a pattern then you have\Nrecovered the key. So it's an old attack,
Dialogue: 0,0:18:43.41,0:18:48.89,Default,,0000,0000,0000,,2006, it's been 10 years, everything\Nshould be fixed by now, and you see where
Dialogue: 0,0:18:48.89,0:18:56.88,Default,,0000,0000,0000,,I'm going: it's not. So on Android the\Nbouncy castle implementation it uses by
Dialogue: 0,0:18:56.88,0:19:03.36,Default,,0000,0000,0000,,default the T-table, so that's bad. Also\Nmany implementations that you can find
Dialogue: 0,0:19:03.36,0:19:11.38,Default,,0000,0000,0000,,online uses pre-computed values, so maybe\Nbe wary about this kind of attacks. The
Dialogue: 0,0:19:11.38,0:19:17.24,Default,,0000,0000,0000,,last application we wanted to show you is\Nhow we can spy on keystrokes.
Dialogue: 0,0:19:17.24,0:19:21.48,Default,,0000,0000,0000,,So for that we will use flush and reload\Nbecause it's a really fine grained
Dialogue: 0,0:19:21.48,0:19:26.31,Default,,0000,0000,0000,,attack. We can see very precisely which\Ncache line has been accessed, and a cache
Dialogue: 0,0:19:26.31,0:19:31.44,Default,,0000,0000,0000,,line is only 64 bytes so it's really not a\Nlot and we're going to use that to spy on
Dialogue: 0,0:19:31.44,0:19:37.69,Default,,0000,0000,0000,,keystrokes and we even have a small demo\Nfor you.
Dialogue: 0,0:19:40.11,0:19:45.64,Default,,0000,0000,0000,,ML: So what you can see on the screen this\Nis not on Intel x86 it's on a smartphone,
Dialogue: 0,0:19:45.64,0:19:50.33,Default,,0000,0000,0000,,on the Galaxy S6, but you can also apply\Nthese cache attacks there so that's what
Dialogue: 0,0:19:50.33,0:19:53.85,Default,,0000,0000,0000,,we want to emphasize.\NSo on the left you see the screen and on
Dialogue: 0,0:19:53.85,0:19:57.96,Default,,0000,0000,0000,,the right we have connected a shell with\Nno privileges and permissions, so it can
Dialogue: 0,0:19:57.96,0:20:00.80,Default,,0000,0000,0000,,basically be an app that you install\N{\i1}glass bottle falling{\i0}
Dialogue: 0,0:20:00.80,0:20:09.48,Default,,0000,0000,0000,,from the App Store and on the right we are\Ngoing to start our spy tool, and on the
Dialogue: 0,0:20:09.48,0:20:14.11,Default,,0000,0000,0000,,left we just open the messenger app and\Nwhenever the user hits any key on the
Dialogue: 0,0:20:14.11,0:20:19.69,Default,,0000,0000,0000,,keyboard our spy tool takes care of that\Nand notices that. Also if he presses the
Dialogue: 0,0:20:19.69,0:20:26.12,Default,,0000,0000,0000,,spacebar we can also measure that. If the\Nuser decides "ok, I want to delete the
Dialogue: 0,0:20:26.12,0:20:30.88,Default,,0000,0000,0000,,word" because he changed his mind, we can\Nalso register if the user pressed the
Dialogue: 0,0:20:30.88,0:20:37.93,Default,,0000,0000,0000,,backspace button, so in the end we can see\Nexactly how long the words were, the user
Dialogue: 0,0:20:37.93,0:20:45.63,Default,,0000,0000,0000,,typed into his phone without any\Npermissions and privileges, which is bad.
Dialogue: 0,0:20:45.63,0:20:55.25,Default,,0000,0000,0000,,{\i1}laughs{\i0}\N{\i1}applause{\i0}
Dialogue: 0,0:20:55.25,0:21:00.32,Default,,0000,0000,0000,,ML: so enough about the mov instruction,\Nlet's head to clflush.
Dialogue: 0,0:21:00.32,0:21:07.23,Default,,0000,0000,0000,,CM: So the clflush instruction: What it\Ndoes is that it invalidates from every
Dialogue: 0,0:21:07.23,0:21:12.31,Default,,0000,0000,0000,,level the cache line that contains the\Naddress that you pass to this instruction.
Dialogue: 0,0:21:12.31,0:21:16.99,Default,,0000,0000,0000,,So in itself it's kind of bad because it\Nenables the Flush+Reload attacks that we
Dialogue: 0,0:21:16.99,0:21:21.30,Default,,0000,0000,0000,,showed earlier, that was just flush,\Nreload, and the flush part is done with
Dialogue: 0,0:21:21.30,0:21:29.14,Default,,0000,0000,0000,,clflush. But there's actually more to it,\Nhow wonderful. So there's a first timing
Dialogue: 0,0:21:29.14,0:21:33.32,Default,,0000,0000,0000,,leakage with it, so we're going to see\Nthat the clflush instruction has a
Dialogue: 0,0:21:33.32,0:21:37.89,Default,,0000,0000,0000,,different timing depending on whether the\Ndata that you that you pass to it is
Dialogue: 0,0:21:37.89,0:21:44.71,Default,,0000,0000,0000,,cached or not. So imagine you have a cache\Nline that is on the level 1 by inclu...
Dialogue: 0,0:21:44.71,0:21:50.30,Default,,0000,0000,0000,,With the inclusion property it has to be\Nalso in the last level cache. Now this is
Dialogue: 0,0:21:50.30,0:21:54.35,Default,,0000,0000,0000,,quite convenient and this is also why we\Nhave this inclusion property for
Dialogue: 0,0:21:54.35,0:22:00.02,Default,,0000,0000,0000,,performance reason on Intel CPUs, if you\Nwant to see if a line is present at all in
Dialogue: 0,0:22:00.02,0:22:04.21,Default,,0000,0000,0000,,the cache you just have to look in the\Nlast level cache. So this is basically
Dialogue: 0,0:22:04.21,0:22:08.01,Default,,0000,0000,0000,,what the clflush instruction does. It goes\Nto the last last level cache, sees "ok
Dialogue: 0,0:22:08.01,0:22:12.89,Default,,0000,0000,0000,,there's a line, I'm going to flush this\None" and then there's something that tells
Dialogue: 0,0:22:12.89,0:22:18.95,Default,,0000,0000,0000,,ok the line is also present somewhere else\Nso then it flushes the line in level 1
Dialogue: 0,0:22:18.95,0:22:26.39,Default,,0000,0000,0000,,and/or level 2. So that's slow. Now if you\Nperform clflush on some data that is not
Dialogue: 0,0:22:26.39,0:22:32.24,Default,,0000,0000,0000,,cached, basically it does the same, goes\Nto the last level cache, see that there's
Dialogue: 0,0:22:32.24,0:22:36.66,Default,,0000,0000,0000,,no line and there can't be any... This\Ndata can't be anywhere else in the cache
Dialogue: 0,0:22:36.66,0:22:41.27,Default,,0000,0000,0000,,because it would be in the last level\Ncache if it was anywhere, so it does
Dialogue: 0,0:22:41.27,0:22:47.43,Default,,0000,0000,0000,,nothing and it stop there. So that's fast.\NSo how exactly fast and slow am I talking
Dialogue: 0,0:22:47.43,0:22:53.76,Default,,0000,0000,0000,,about? So it's actually only a very few\Ncycles so we did this experiments on
Dialogue: 0,0:22:53.76,0:22:59.07,Default,,0000,0000,0000,,different microarchitecture so Center\NBridge, Ivy Bridge, and Haswell and...
Dialogue: 0,0:22:59.07,0:23:03.25,Default,,0000,0000,0000,,So it different colors correspond to the\Ndifferent microarchitecture. So first
Dialogue: 0,0:23:03.25,0:23:07.88,Default,,0000,0000,0000,,thing that is already... kinda funny is\Nthat you can see that you can distinguish
Dialogue: 0,0:23:07.88,0:23:14.65,Default,,0000,0000,0000,,the micro architecture quite nicely with\Nthis, but the real point is that you have
Dialogue: 0,0:23:14.65,0:23:20.28,Default,,0000,0000,0000,,really a different zones. The solids...\NThe solid line is when we performed the
Dialogue: 0,0:23:20.28,0:23:25.20,Default,,0000,0000,0000,,measurement on clflush with the line that\Nwas already in the cache, and the dashed
Dialogue: 0,0:23:25.20,0:23:30.84,Default,,0000,0000,0000,,line is when the line was not in the\Ncache, and in all microarchitectures you
Dialogue: 0,0:23:30.84,0:23:36.54,Default,,0000,0000,0000,,can see that we can see a difference: It's\Nonly a few cycles, it's a bit noisy, so
Dialogue: 0,0:23:36.54,0:23:43.25,Default,,0000,0000,0000,,what could go wrong? Okay, so exploiting\Nthese few cycles, we still managed to
Dialogue: 0,0:23:43.25,0:23:47.03,Default,,0000,0000,0000,,perform a new cache attacks that we call\N"Flush+Flush", so I'm going to explain
Dialogue: 0,0:23:47.03,0:23:52.22,Default,,0000,0000,0000,,that to you: So basically everything that\Nwe could do with "Flush+Reload", we can
Dialogue: 0,0:23:52.22,0:23:56.90,Default,,0000,0000,0000,,also do with "Flush+Flush". We can perform\Ncover channels and sidechannel attacks.
Dialogue: 0,0:23:56.90,0:24:01.09,Default,,0000,0000,0000,,It's stealthier than previous cache\Nattacks, I'm going to go back on this one,
Dialogue: 0,0:24:01.09,0:24:07.22,Default,,0000,0000,0000,,and it's also faster than previous cache\Nattacks. So how does it work exactly? So
Dialogue: 0,0:24:07.22,0:24:12.21,Default,,0000,0000,0000,,the principle is a bit similar to\N"Flush+Reload": So we have the attacker
Dialogue: 0,0:24:12.21,0:24:16.13,Default,,0000,0000,0000,,and the victim that have some kind of\Nshared memory, let's say a shared library.
Dialogue: 0,0:24:16.13,0:24:21.34,Default,,0000,0000,0000,,It will be shared in the cache The\Nattacker will start by flushing the cache
Dialogue: 0,0:24:21.34,0:24:26.51,Default,,0000,0000,0000,,line then let's the victim perform\Nwhatever it does, let's say encryption,
Dialogue: 0,0:24:26.51,0:24:32.12,Default,,0000,0000,0000,,the victim will load some data into the\Ncache, automatically, and now the attacker
Dialogue: 0,0:24:32.12,0:24:36.72,Default,,0000,0000,0000,,wants to know again if the victim accessed\Nthis precise cache line and instead of
Dialogue: 0,0:24:36.72,0:24:43.54,Default,,0000,0000,0000,,reloading it is going to flush it again.\NAnd since we have this timing difference
Dialogue: 0,0:24:43.54,0:24:47.04,Default,,0000,0000,0000,,depending on whether the data is in the\Ncache or not, it gives us the same
Dialogue: 0,0:24:47.04,0:24:54.89,Default,,0000,0000,0000,,information as if we reloaded it, except\Nit's way faster. So I talked about
Dialogue: 0,0:24:54.89,0:24:59.69,Default,,0000,0000,0000,,stealthiness. So the thing is that\Nbasically these cache attacks and that
Dialogue: 0,0:24:59.69,0:25:06.34,Default,,0000,0000,0000,,also applies to "Rowhammer": They are\Nalready stealth in themselves, because
Dialogue: 0,0:25:06.34,0:25:10.47,Default,,0000,0000,0000,,there's no antivirus today that can detect\Nthem. but some people thought that we
Dialogue: 0,0:25:10.47,0:25:14.35,Default,,0000,0000,0000,,could detect them with performance\Ncounters because they do a lot of cache
Dialogue: 0,0:25:14.35,0:25:18.55,Default,,0000,0000,0000,,misses and cache references that happen\Nwhen the data is flushed and when you
Dialogue: 0,0:25:18.55,0:25:26.09,Default,,0000,0000,0000,,reaccess memory. now what we thought is\Nthat yeah but that also not the only
Dialogue: 0,0:25:26.09,0:25:31.27,Default,,0000,0000,0000,,program steps to lots of cache misses and\Ncache references so we would like to have
Dialogue: 0,0:25:31.27,0:25:38.12,Default,,0000,0000,0000,,a slightly parametric. So these cache\Nattacks they have a very heavy activity on
Dialogue: 0,0:25:38.12,0:25:43.84,Default,,0000,0000,0000,,the cache but they're also very particular\Nbecause there are very short loops of code
Dialogue: 0,0:25:43.84,0:25:48.61,Default,,0000,0000,0000,,if you take flush and reload this just\Nflush one line reload the line and then
Dialogue: 0,0:25:48.61,0:25:53.75,Default,,0000,0000,0000,,again flush reload that's very short loop\Nand that creates a very low pressure on
Dialogue: 0,0:25:53.75,0:26:01.49,Default,,0000,0000,0000,,the instruction therapy which is kind of\Nparticular for of cache attacks so what we
Dialogue: 0,0:26:01.49,0:26:05.38,Default,,0000,0000,0000,,decided to do is normalizing the cache\Neven so the cache misses and cache
Dialogue: 0,0:26:05.38,0:26:10.72,Default,,0000,0000,0000,,references by events that have to do with\Nthe instruction TLB and there we could
Dialogue: 0,0:26:10.72,0:26:19.36,Default,,0000,0000,0000,,manage to detect cache attacks and\NRowhammer without having false positives
Dialogue: 0,0:26:19.36,0:26:24.51,Default,,0000,0000,0000,,so the system metric that I'm going to use\Nwhen I talk about stealthiness so we
Dialogue: 0,0:26:24.51,0:26:29.75,Default,,0000,0000,0000,,started by creating a cover channel. First\Nwe wanted to have it as fast as possible
Dialogue: 0,0:26:29.75,0:26:36.16,Default,,0000,0000,0000,,so we created a protocol to evaluates all\Nthe kind of cache attack that we had so
Dialogue: 0,0:26:36.16,0:26:40.54,Default,,0000,0000,0000,,flush+flush, flush+reload, and\Nprime+probe and we started with a
Dialogue: 0,0:26:40.54,0:26:47.01,Default,,0000,0000,0000,,packet side of 28 doesn't really matter.\NWe measured the capacity of our covert
Dialogue: 0,0:26:47.01,0:26:52.80,Default,,0000,0000,0000,,channel and flush+flush is around\N500 kB/s whereas Flush+Reload
Dialogue: 0,0:26:52.80,0:26:56.34,Default,,0000,0000,0000,,was only 300 kB/s\Nso Flush+Flush is already quite an
Dialogue: 0,0:26:56.34,0:27:00.74,Default,,0000,0000,0000,,improvement on the speed.\NThen we measured the stealth zone at this
Dialogue: 0,0:27:00.74,0:27:06.10,Default,,0000,0000,0000,,speed only Flush+Flush was stealth and\Nnow the thing is that Flush+Flush and
Dialogue: 0,0:27:06.10,0:27:10.20,Default,,0000,0000,0000,,Flush+Reload as you've seen there are\Nsome similarities so for a covert channel
Dialogue: 0,0:27:10.20,0:27:15.31,Default,,0000,0000,0000,,they also share the same center on it is\Nreceivers different and for this one the
Dialogue: 0,0:27:15.31,0:27:20.00,Default,,0000,0000,0000,,center was not stealth for both of them\Nanyway if you want a fast covert channel
Dialogue: 0,0:27:20.00,0:27:26.64,Default,,0000,0000,0000,,then just try flush+flush that works.\NNow let's try to make it stealthy
Dialogue: 0,0:27:26.64,0:27:30.64,Default,,0000,0000,0000,,completely stealthy because if I have the\Nstandard that is not stealth maybe that we
Dialogue: 0,0:27:30.64,0:27:36.44,Default,,0000,0000,0000,,give away the whole attack so we said okay\Nmaybe if we just slow down all the attacks
Dialogue: 0,0:27:36.44,0:27:41.24,Default,,0000,0000,0000,,then there will be less cache hits,\Ncache misses and then maybe all
Dialogue: 0,0:27:41.24,0:27:48.07,Default,,0000,0000,0000,,the attacks are actually stealthy why not?\NSo we tried that we slowed down everything
Dialogue: 0,0:27:48.07,0:27:52.89,Default,,0000,0000,0000,,so Flush+Reload and Flash+Flash\Nare around 50 kB/s now
Dialogue: 0,0:27:52.89,0:27:55.83,Default,,0000,0000,0000,,Prime+Probe is a bit slower because it\Ntakes more time
Dialogue: 0,0:27:55.83,0:28:01.33,Default,,0000,0000,0000,,to prime and probe anything but still
Dialogue: 0,0:28:01.33,0:28:09.42,Default,,0000,0000,0000,,even with this slow down only Flush+Flush\Nhas its receiver stealth and we also
Dialogue: 0,0:28:09.42,0:28:14.77,Default,,0000,0000,0000,,managed to have the sender stealth now so\Nbasically whether you want a fast covert
Dialogue: 0,0:28:14.77,0:28:20.45,Default,,0000,0000,0000,,channel or a stealth covert channel\NFlush+Flush is really great.
Dialogue: 0,0:28:20.45,0:28:26.50,Default,,0000,0000,0000,,Now we wanted to also evaluate if it\Nwasn't too noisy to perform some side
Dialogue: 0,0:28:26.50,0:28:30.74,Default,,0000,0000,0000,,channel attack so we did these side\Nchannels on the AES t-table implementation
Dialogue: 0,0:28:30.74,0:28:35.91,Default,,0000,0000,0000,,the attacks that we have shown you\Nearlier, so we computed a lot of
Dialogue: 0,0:28:35.91,0:28:41.82,Default,,0000,0000,0000,,encryption that we needed to determine the\Nupper four bits of a key bytes so here the
Dialogue: 0,0:28:41.82,0:28:48.87,Default,,0000,0000,0000,,lower the better the attack and Flush +\NReload is a bit better so we need only 250
Dialogue: 0,0:28:48.87,0:28:55.03,Default,,0000,0000,0000,,encryptions to recover these bits but\NFlush+Flush comes quite, comes quite
Dialogue: 0,0:28:55.03,0:29:00.57,Default,,0000,0000,0000,,close with 350 and Prime+Probe is\Nactually the most noisy of them all, needs
Dialogue: 0,0:29:00.57,0:29:06.10,Default,,0000,0000,0000,,5... close to 5000 encryptions so we have\Naround the same performance for
Dialogue: 0,0:29:06.10,0:29:13.52,Default,,0000,0000,0000,,Flush+Flush and Flush+Reload.\NNow let's evaluate the stealthiness again.
Dialogue: 0,0:29:13.52,0:29:19.32,Default,,0000,0000,0000,,So what we did here is we perform 256\Nbillion encryptions in a synchronous
Dialogue: 0,0:29:19.32,0:29:25.74,Default,,0000,0000,0000,,attack so we really had the spy and the\Nvictim scattered and we evaluated the
Dialogue: 0,0:29:25.74,0:29:31.41,Default,,0000,0000,0000,,stealthiness of them all and here only\NFlush+Flush again is stealth. And while
Dialogue: 0,0:29:31.41,0:29:36.28,Default,,0000,0000,0000,,you can always slow down a covert channel\Nyou can't actually slow down a side
Dialogue: 0,0:29:36.28,0:29:40.70,Default,,0000,0000,0000,,channel because, in a real-life scenario,\Nyou're not going to say "Hey victim, him
Dialogue: 0,0:29:40.70,0:29:47.18,Default,,0000,0000,0000,,wait for me a bit, I am trying to do an\Nattack here." That won't work.
Dialogue: 0,0:29:47.18,0:29:51.43,Default,,0000,0000,0000,,So there's even more to it but I will need\Nagain a bit of background before
Dialogue: 0,0:29:51.43,0:29:56.91,Default,,0000,0000,0000,,continuing. So I've shown you the\Ndifferent levels of caches and here I'm
Dialogue: 0,0:29:56.91,0:30:04.01,Default,,0000,0000,0000,,going to focus more on the last-level\Ncache. So we have here our four slices so
Dialogue: 0,0:30:04.01,0:30:09.83,Default,,0000,0000,0000,,this is the last-level cache and we have\Nsome bits of the address here that
Dialogue: 0,0:30:09.83,0:30:14.33,Default,,0000,0000,0000,,corresponds to the set, but more\Nimportantly, we need to know where in
Dialogue: 0,0:30:14.33,0:30:19.90,Default,,0000,0000,0000,,which slice and address is going to be.\NAnd that is given, that is given by some
Dialogue: 0,0:30:19.90,0:30:23.85,Default,,0000,0000,0000,,bits of the set and the type of the\Naddress that are passed into a function
Dialogue: 0,0:30:23.85,0:30:27.96,Default,,0000,0000,0000,,that says in which slice the line is going\Nto be.
Dialogue: 0,0:30:27.96,0:30:32.46,Default,,0000,0000,0000,,Now the thing is that this hash function\Nis undocumented by Intel. Wouldn't be fun
Dialogue: 0,0:30:32.46,0:30:39.25,Default,,0000,0000,0000,,otherwise. So we have this: As many slices\Nas core, an undocumented hash function
Dialogue: 0,0:30:39.25,0:30:43.98,Default,,0000,0000,0000,,that maps a physical address to a slice,\Nand while it's actually a bit of a pain
Dialogue: 0,0:30:43.98,0:30:48.71,Default,,0000,0000,0000,,for attacks, it has, it was not designed\Nfor security originally but for
Dialogue: 0,0:30:48.71,0:30:53.57,Default,,0000,0000,0000,,performance, because you want all the\Naccess to be evenly distributed in the
Dialogue: 0,0:30:53.57,0:31:00.40,Default,,0000,0000,0000,,different slices, for performance reasons.\NSo the hash function basically does, it
Dialogue: 0,0:31:00.40,0:31:05.28,Default,,0000,0000,0000,,takes some bits of the physical address\Nand output k bits of slice, so just one
Dialogue: 0,0:31:05.28,0:31:09.31,Default,,0000,0000,0000,,bits if you have a two-core machine, two\Nbits if you have a four-core machine and
Dialogue: 0,0:31:09.31,0:31:16.83,Default,,0000,0000,0000,,so on. Now let's go back to clflush, see\Nwhat's the relation with that.
Dialogue: 0,0:31:16.83,0:31:21.17,Default,,0000,0000,0000,,So the thing that we noticed is that\Nclflush is actually faster to reach a line
Dialogue: 0,0:31:21.17,0:31:28.55,Default,,0000,0000,0000,,on the local slice.\NSo if you have, if you're flushing always
Dialogue: 0,0:31:28.55,0:31:33.34,Default,,0000,0000,0000,,one line and you run your program on core\Nzero, core one, core two and core three,
Dialogue: 0,0:31:33.34,0:31:37.90,Default,,0000,0000,0000,,you will observe that one core in\Nparticular on, when you run the program on
Dialogue: 0,0:31:37.90,0:31:44.63,Default,,0000,0000,0000,,one core, the clflush is faster. And so\Nhere this is on core one, and you can see
Dialogue: 0,0:31:44.63,0:31:51.14,Default,,0000,0000,0000,,that core zero, two, and three it's, it's\Na bit slower and here we can deduce that,
Dialogue: 0,0:31:51.14,0:31:55.32,Default,,0000,0000,0000,,so we run the program on core one and we\Nflush always the same line and we can
Dialogue: 0,0:31:55.32,0:32:01.85,Default,,0000,0000,0000,,deduce that the line belong to slice one.\NAnd what we can do with that is that we
Dialogue: 0,0:32:01.85,0:32:06.50,Default,,0000,0000,0000,,can map physical address to slices.\NAnd that's one way to reverse-engineer
Dialogue: 0,0:32:06.50,0:32:10.64,Default,,0000,0000,0000,,this addressing function that was not\Ndocumented.
Dialogue: 0,0:32:10.64,0:32:15.88,Default,,0000,0000,0000,,Funnily enough that's not the only way:\NWhat I did before that was using the
Dialogue: 0,0:32:15.88,0:32:21.23,Default,,0000,0000,0000,,performance counters to reverse-engineer\Nthis function, but that's actually a whole
Dialogue: 0,0:32:21.23,0:32:27.77,Default,,0000,0000,0000,,other story and if you want more detail on\Nthat, there's also an article on that.
Dialogue: 0,0:32:27.77,0:32:30.14,Default,,0000,0000,0000,,ML: So the next instruction we want to
Dialogue: 0,0:32:30.14,0:32:35.11,Default,,0000,0000,0000,,talk about is the prefetch instruction.\NAnd the prefetch instruction is used to
Dialogue: 0,0:32:35.11,0:32:40.84,Default,,0000,0000,0000,,tell the CPU: "Okay, please load the data\NI need later on, into the cache, if you
Dialogue: 0,0:32:40.84,0:32:45.97,Default,,0000,0000,0000,,have some time." And in the end there are\Nactually six different prefetch
Dialogue: 0,0:32:45.97,0:32:52.93,Default,,0000,0000,0000,,instructions: prefetcht0 to t2 which\Nmeans: "CPU, please load the data into the
Dialogue: 0,0:32:52.93,0:32:58.64,Default,,0000,0000,0000,,first-level cache", or in the last-level\Ncache, whatever you want to use, but we
Dialogue: 0,0:32:58.64,0:33:02.25,Default,,0000,0000,0000,,spare you the details because it's not so\Ninteresting in the end.
Dialogue: 0,0:33:02.25,0:33:06.94,Default,,0000,0000,0000,,However, what's more interesting is when\Nwe take a look at the Intel manual and
Dialogue: 0,0:33:06.94,0:33:11.88,Default,,0000,0000,0000,,what it says there. So, "Using the\NPREFETCH instruction is recommended only
Dialogue: 0,0:33:11.88,0:33:17.05,Default,,0000,0000,0000,,if data does not fit in the cache." So you\Ncan tell the CPU: "Please load data I want
Dialogue: 0,0:33:17.05,0:33:23.21,Default,,0000,0000,0000,,to stream into the cache, so it's more\Nperformant." "Use of software prefetch
Dialogue: 0,0:33:23.21,0:33:27.74,Default,,0000,0000,0000,,should be limited to memory addresses that\Nare managed or owned within the
Dialogue: 0,0:33:27.74,0:33:33.62,Default,,0000,0000,0000,,application context."\NSo one might wonder what happens if this
Dialogue: 0,0:33:33.62,0:33:40.94,Default,,0000,0000,0000,,address is not managed by myself. Sounds\Ninteresting. "Prefetching to addresses
Dialogue: 0,0:33:40.94,0:33:46.29,Default,,0000,0000,0000,,that are not mapped to physical pages can\Nexperience non-deterministic performance
Dialogue: 0,0:33:46.29,0:33:52.03,Default,,0000,0000,0000,,penalty. For example specifying a NULL\Npointer as an address for prefetch can
Dialogue: 0,0:33:52.03,0:33:56.00,Default,,0000,0000,0000,,cause long delays."\NSo we don't want to do that because our
Dialogue: 0,0:33:56.00,0:34:02.92,Default,,0000,0000,0000,,program will be slow. So, let's take a\Nlook what they mean with non-deterministic
Dialogue: 0,0:34:02.92,0:34:08.89,Default,,0000,0000,0000,,performance penalty, because we want to\Nwrite good software, right? But before
Dialogue: 0,0:34:08.89,0:34:12.51,Default,,0000,0000,0000,,that, we have to take a look at a little\Nbit more background information to
Dialogue: 0,0:34:12.51,0:34:17.71,Default,,0000,0000,0000,,understand the attacks.\NSo on modern operating systems, every
Dialogue: 0,0:34:17.71,0:34:22.85,Default,,0000,0000,0000,,application has its own virtual address\Nspace. So at some point, the CPU needs to
Dialogue: 0,0:34:22.85,0:34:27.48,Default,,0000,0000,0000,,translate these addresses to the physical\Naddresses actually in the DRAM. And for
Dialogue: 0,0:34:27.48,0:34:33.69,Default,,0000,0000,0000,,that we have this very complex-looking\Ndata structure. So we have a 48-bit
Dialogue: 0,0:34:33.69,0:34:40.41,Default,,0000,0000,0000,,virtual address, and some of those bits\Nmapped to a table, like the PM level 4
Dialogue: 0,0:34:40.41,0:34:47.76,Default,,0000,0000,0000,,table, with 512 entries, so depending on\Nthose bits the CPU knows, at which line he
Dialogue: 0,0:34:47.76,0:34:51.52,Default,,0000,0000,0000,,has to look.\NAnd if there is data there, because the
Dialogue: 0,0:34:51.52,0:34:56.90,Default,,0000,0000,0000,,address is mapped, he can proceed and look\Nat the page directory, point the table,
Dialogue: 0,0:34:56.90,0:35:04.62,Default,,0000,0000,0000,,and so on for the town. So is everything,\Nis the same for each level until you come
Dialogue: 0,0:35:04.62,0:35:09.13,Default,,0000,0000,0000,,to your page table, where you have\N4-kilobyte pages. So it's in the end not
Dialogue: 0,0:35:09.13,0:35:13.85,Default,,0000,0000,0000,,that complicated, but it's a bit\Nconfusing, because you want to know a
Dialogue: 0,0:35:13.85,0:35:20.31,Default,,0000,0000,0000,,physical address, so you have to look it\Nup somewhere in the, in the main memory
Dialogue: 0,0:35:20.31,0:35:25.42,Default,,0000,0000,0000,,with physical addresses to translate your\Nvirtual addresses. And if you have to go
Dialogue: 0,0:35:25.42,0:35:31.89,Default,,0000,0000,0000,,through all those levels, it needs a long\Ntime, so we can do better than that and
Dialogue: 0,0:35:31.89,0:35:39.16,Default,,0000,0000,0000,,that's why Intel introduced additional\Ncaches, also for all of those levels. So,
Dialogue: 0,0:35:39.16,0:35:45.56,Default,,0000,0000,0000,,if you want to translate an address, you\Ntake a look at the ITLB for instructions,
Dialogue: 0,0:35:45.56,0:35:51.15,Default,,0000,0000,0000,,and the data TLB for data. If it's there,\Nyou can stop, otherwise you go down all
Dialogue: 0,0:35:51.15,0:35:58.70,Default,,0000,0000,0000,,those levels and if it's not in any cache\Nyou have to look it up in the DRAM. In
Dialogue: 0,0:35:58.70,0:36:03.30,Default,,0000,0000,0000,,addition, the address space you have is\Nshared, because you have, on the one hand,
Dialogue: 0,0:36:03.30,0:36:07.47,Default,,0000,0000,0000,,the user memory and, on the other hand,\Nyou have mapped the kernel for convenience
Dialogue: 0,0:36:07.47,0:36:12.87,Default,,0000,0000,0000,,and performance also in the address space.\NAnd if your user program wants to access
Dialogue: 0,0:36:12.87,0:36:18.31,Default,,0000,0000,0000,,some kernel functionality like reading a\Nfile, it will switch to the kernel memory
Dialogue: 0,0:36:18.31,0:36:23.88,Default,,0000,0000,0000,,there's a privilege escalation, and then\Nyou can read the file, and so on. So,
Dialogue: 0,0:36:23.88,0:36:30.42,Default,,0000,0000,0000,,that's it. However, you have drivers in\Nthe kernel, and if you know the addresses
Dialogue: 0,0:36:30.42,0:36:35.77,Default,,0000,0000,0000,,of those drivers, you can do code-reuse\Nattacks, and as a countermeasure, they
Dialogue: 0,0:36:35.77,0:36:40.15,Default,,0000,0000,0000,,introduced address-space layout\Nrandomization, also for the kernel.
Dialogue: 0,0:36:40.15,0:36:47.04,Default,,0000,0000,0000,,And this means that when you have your\Nprogram running, the kernel is mapped at
Dialogue: 0,0:36:47.04,0:36:51.63,Default,,0000,0000,0000,,one address and if you reboot the machine\Nit's not on the same address anymore but
Dialogue: 0,0:36:51.63,0:36:58.39,Default,,0000,0000,0000,,somewhere else. So if there is a way to\Nfind out at which address the kernel is
Dialogue: 0,0:36:58.39,0:37:04.45,Default,,0000,0000,0000,,loaded, you have circumvented this\Ncountermeasure and defeated kernel address
Dialogue: 0,0:37:04.45,0:37:11.06,Default,,0000,0000,0000,,space layout randomization. So this would\Nbe nice for some attacks. In addition,
Dialogue: 0,0:37:11.06,0:37:16.95,Default,,0000,0000,0000,,there's also the kernel direct physical\Nmap. And what does this mean? It's
Dialogue: 0,0:37:16.95,0:37:23.32,Default,,0000,0000,0000,,implemented on many operating systems like\NOS X, Linux, also on the Xen hypervisor
Dialogue: 0,0:37:23.32,0:37:27.86,Default,,0000,0000,0000,,and\NBSD, but not on Windows. But what it means
Dialogue: 0,0:37:27.86,0:37:33.87,Default,,0000,0000,0000,,is that the complete physical memory is\Nmapped in additionally in the kernel
Dialogue: 0,0:37:33.87,0:37:40.46,Default,,0000,0000,0000,,memory at a fixed offset. So, for every\Npage that is mapped in the user space,
Dialogue: 0,0:37:40.46,0:37:45.16,Default,,0000,0000,0000,,there's something like a twin page in the\Nkernel memory, which you can't access
Dialogue: 0,0:37:45.16,0:37:50.37,Default,,0000,0000,0000,,because it's in the kernel memory.\NHowever, we will need it later, because
Dialogue: 0,0:37:50.37,0:37:58.23,Default,,0000,0000,0000,,now we go back to prefetch and see what we\Ncan do with that. So, prefetch is not a
Dialogue: 0,0:37:58.23,0:38:04.15,Default,,0000,0000,0000,,usual instruction, because it just tells\Nthe CPU "I might need that data later on.
Dialogue: 0,0:38:04.15,0:38:10.00,Default,,0000,0000,0000,,If you have time, load for me," if not,\Nthe CPU can ignore it because it's busy
Dialogue: 0,0:38:10.00,0:38:15.81,Default,,0000,0000,0000,,with other stuff. So, there's no necessity\Nthat this instruction is really executed,
Dialogue: 0,0:38:15.81,0:38:22.07,Default,,0000,0000,0000,,but most of the time it is. And a nice,\Ninteresting thing is that it generates no
Dialogue: 0,0:38:22.07,0:38:29.00,Default,,0000,0000,0000,,faults, so whatever you pass to this\Ninstruction, your program won't crash, and
Dialogue: 0,0:38:29.00,0:38:33.99,Default,,0000,0000,0000,,it does not check any privileges, so I can\Nalso pass an kernel address to it and it
Dialogue: 0,0:38:33.99,0:38:37.51,Default,,0000,0000,0000,,won't say "No, stop, you accessed an\Naddress that you are not allowed to
Dialogue: 0,0:38:37.51,0:38:45.53,Default,,0000,0000,0000,,access, so I crash," it just continues,\Nwhich is nice.
Dialogue: 0,0:38:45.53,0:38:49.81,Default,,0000,0000,0000,,The second interesting thing is that the\Noperand is a virtual address, so every
Dialogue: 0,0:38:49.81,0:38:55.53,Default,,0000,0000,0000,,time you execute this instruction, the CPU\Nhas to go and check "OK, what physical
Dialogue: 0,0:38:55.53,0:38:59.60,Default,,0000,0000,0000,,address does this virtual address\Ncorrespond to?" So it has to do the lookup
Dialogue: 0,0:38:59.60,0:39:05.75,Default,,0000,0000,0000,,with all those tables we've seen earlier,\Nand as you probably have guessed already,
Dialogue: 0,0:39:05.75,0:39:10.37,Default,,0000,0000,0000,,the execution time varies also for the\Nprefetch instruction and we will see later
Dialogue: 0,0:39:10.37,0:39:16.09,Default,,0000,0000,0000,,on what we can do with that.\NSo, let's get back to the direct physical
Dialogue: 0,0:39:16.09,0:39:22.87,Default,,0000,0000,0000,,map. Because we can create an oracle for\Naddress translation, so we can find out
Dialogue: 0,0:39:22.87,0:39:27.54,Default,,0000,0000,0000,,what physical address belongs to the\Nvirtual address. Because nowadays you
Dialogue: 0,0:39:27.54,0:39:31.99,Default,,0000,0000,0000,,don't want that the user to know, because\Nyou can craft nice rowhammer attacks with
Dialogue: 0,0:39:31.99,0:39:37.52,Default,,0000,0000,0000,,that information, and more advanced cache\Nattacks, so you restrict this information
Dialogue: 0,0:39:37.52,0:39:44.27,Default,,0000,0000,0000,,to the user. But let's check if we find a\Nway to still get this information. So, as
Dialogue: 0,0:39:44.27,0:39:50.15,Default,,0000,0000,0000,,I've told you earlier, if you have a\Npaired page in the user space map,
Dialogue: 0,0:39:50.15,0:39:54.50,Default,,0000,0000,0000,,you have the twin page in the kernel \Nspace, and if it's cached,
Dialogue: 0,0:39:54.50,0:39:56.71,Default,,0000,0000,0000,,its cached for both of them again.
Dialogue: 0,0:39:56.71,0:40:03.17,Default,,0000,0000,0000,,So, the attack now works as the following:\NFrom the attacker you flush your user
Dialogue: 0,0:40:03.17,0:40:09.76,Default,,0000,0000,0000,,space page, so it's not in the cache for\Nthe... also for the kernel memory, and
Dialogue: 0,0:40:09.76,0:40:15.85,Default,,0000,0000,0000,,then you call prefetch on the address of\Nthe kernel, because as I told you, you
Dialogue: 0,0:40:15.85,0:40:22.05,Default,,0000,0000,0000,,still can do that because it doesn't\Ncreate any faults. So, you tell the CPU
Dialogue: 0,0:40:22.05,0:40:28.31,Default,,0000,0000,0000,,"Please load me this data into the cache\Neven if I don't have access to this data
Dialogue: 0,0:40:28.31,0:40:32.55,Default,,0000,0000,0000,,normally."\NAnd if we now measure on our user space
Dialogue: 0,0:40:32.55,0:40:37.10,Default,,0000,0000,0000,,page the address again, and we measure a\Ncache hit, because it has been loaded by
Dialogue: 0,0:40:37.10,0:40:42.63,Default,,0000,0000,0000,,the CPU into the cache, we know exactly at\Nwhich position, since we passed the
Dialogue: 0,0:40:42.63,0:40:48.25,Default,,0000,0000,0000,,address to the function, this address\Ncorresponds to. And because this is at a
Dialogue: 0,0:40:48.25,0:40:53.28,Default,,0000,0000,0000,,fixed offset, we can just do a simple\Nsubtraction and know the physical address
Dialogue: 0,0:40:53.28,0:40:59.18,Default,,0000,0000,0000,,again. So we have a nice way to find\Nphysical addresses for virtual addresses.
Dialogue: 0,0:40:59.18,0:41:04.39,Default,,0000,0000,0000,,And in practice this looks like this\Nfollowing plot. So, it's pretty simple,
Dialogue: 0,0:41:04.39,0:41:08.91,Default,,0000,0000,0000,,because we just do this for every address,\Nand at some point we measure a cache hit.
Dialogue: 0,0:41:08.91,0:41:14.26,Default,,0000,0000,0000,,So, there's a huge difference. And exactly\Nat this point we know this physical
Dialogue: 0,0:41:14.26,0:41:20.14,Default,,0000,0000,0000,,address corresponds to our virtual\Naddress. The second thing is that we can
Dialogue: 0,0:41:20.14,0:41:27.07,Default,,0000,0000,0000,,exploit the timing differences it needs\Nfor the prefetch instruction. Because, as
Dialogue: 0,0:41:27.07,0:41:31.85,Default,,0000,0000,0000,,I told you, when you go down this cache\Nlevels, at some point you see "it's here"
Dialogue: 0,0:41:31.85,0:41:37.50,Default,,0000,0000,0000,,or "it's not here," so it can abort early.\NAnd with that we can know exactly
Dialogue: 0,0:41:37.50,0:41:41.80,Default,,0000,0000,0000,,when the prefetch\Ninstruction aborted, and know how the
Dialogue: 0,0:41:41.80,0:41:48.07,Default,,0000,0000,0000,,pages are mapped into the address space.\NSo, the timing depends on where the
Dialogue: 0,0:41:48.07,0:41:57.09,Default,,0000,0000,0000,,translation stops. And using those two\Nproperties and those information, we can
Dialogue: 0,0:41:57.09,0:42:02.23,Default,,0000,0000,0000,,do the following: On the one hand, we can\Nbuild variants of cache attacks. So,
Dialogue: 0,0:42:02.23,0:42:07.44,Default,,0000,0000,0000,,instead of Flush+Reload, we can do\NFlush+Prefetch, for instance. We can
Dialogue: 0,0:42:07.44,0:42:12.06,Default,,0000,0000,0000,,also use prefetch to mount rowhammer\Nattacks on privileged addresses, because
Dialogue: 0,0:42:12.06,0:42:18.07,Default,,0000,0000,0000,,it doesn't do any faults when we pass\Nthose addresses, and it works as well. In
Dialogue: 0,0:42:18.07,0:42:23.33,Default,,0000,0000,0000,,addition, we can use it to recover the\Ntranslation levels of a process, which you
Dialogue: 0,0:42:23.33,0:42:27.87,Default,,0000,0000,0000,,could do earlier with the page map file,\Nbut as I told you it's now privileged, so
Dialogue: 0,0:42:27.87,0:42:32.89,Default,,0000,0000,0000,,you don't have access to that, and by\Ndoing that you can bypass address space
Dialogue: 0,0:42:32.89,0:42:38.17,Default,,0000,0000,0000,,layout randomization. In addition, as I\Ntold you, you can translate virtual
Dialogue: 0,0:42:38.17,0:42:43.53,Default,,0000,0000,0000,,addresses to physical addresses, which is\Nnow also privileged with the page map
Dialogue: 0,0:42:43.53,0:42:48.79,Default,,0000,0000,0000,,file, and using that it reenables return\Nto direct exploits, which have been
Dialogue: 0,0:42:48.79,0:42:55.55,Default,,0000,0000,0000,,demonstrated last year. On top of that, we\Ncan also use this to locate kernel
Dialogue: 0,0:42:55.55,0:43:00.85,Default,,0000,0000,0000,,drivers, as I told you. It would be nice\Nif we can circumvent KSLR as well, and I
Dialogue: 0,0:43:00.85,0:43:08.38,Default,,0000,0000,0000,,will show you now how this is possible.\NSo, with the first oracle we find out all
Dialogue: 0,0:43:08.38,0:43:15.43,Default,,0000,0000,0000,,the pages that are mapped, and for each of\Nthose pages, we evict the translation
Dialogue: 0,0:43:15.43,0:43:18.21,Default,,0000,0000,0000,,caches, and we can do that by either\Ncalling sleep,
Dialogue: 0,0:43:18.21,0:43:24.45,Default,,0000,0000,0000,,which schedules another program, or access\Njust a large memory buffer. Then, we
Dialogue: 0,0:43:24.45,0:43:28.26,Default,,0000,0000,0000,,perform a syscall to the driver. So,\Nthere's code of the driver executed and
Dialogue: 0,0:43:28.26,0:43:33.54,Default,,0000,0000,0000,,loaded into the cache, and then we just\Nmeasure the time prefetch takes on this
Dialogue: 0,0:43:33.54,0:43:40.84,Default,,0000,0000,0000,,address. And in the end, the fastest\Naverage access time is the driver page.
Dialogue: 0,0:43:40.84,0:43:46.77,Default,,0000,0000,0000,,So, we can mount this attack on Windows 10\Nin less than 12 seconds. So, we can defeat
Dialogue: 0,0:43:46.77,0:43:52.11,Default,,0000,0000,0000,,KSLR in less than 12 seconds, which is\Nvery nice. And in practice, the
Dialogue: 0,0:43:52.11,0:43:58.33,Default,,0000,0000,0000,,measurements looks like the following: So,\Nwe have a lot of long measurements, and at
Dialogue: 0,0:43:58.33,0:44:05.06,Default,,0000,0000,0000,,some point you have a low one, and you\Nknow exactly that this driver region and
Dialogue: 0,0:44:05.06,0:44:09.93,Default,,0000,0000,0000,,the address the driver is located. And\Nyou can mount those read to direct
Dialogue: 0,0:44:09.93,0:44:16.21,Default,,0000,0000,0000,,attacks again. However, that's not\Neverything, because there are more
Dialogue: 0,0:44:16.21,0:44:20.80,Default,,0000,0000,0000,,instructions in Intel.\NCM: Yeah, so, the following is not our
Dialogue: 0,0:44:20.80,0:44:24.35,Default,,0000,0000,0000,,work, but we thought that would be\Ninteresting, because it's basically more
Dialogue: 0,0:44:24.35,0:44:30.74,Default,,0000,0000,0000,,instructions, more attacks, more fun. So\Nthere's the RDSEED instruction, and what
Dialogue: 0,0:44:30.74,0:44:35.34,Default,,0000,0000,0000,,it does, that is request a random seed to\Nthe hardware random number generator. So,
Dialogue: 0,0:44:35.34,0:44:39.31,Default,,0000,0000,0000,,the thing is that there is a fixed number\Nof precomputed random bits, and that takes
Dialogue: 0,0:44:39.31,0:44:44.32,Default,,0000,0000,0000,,time to regenerate them. So, as everything\Nthat takes time, you can create a covert
Dialogue: 0,0:44:44.32,0:44:50.18,Default,,0000,0000,0000,,channel with that. There is also FADD and\NFMUL, which are floating point operations.
Dialogue: 0,0:44:50.18,0:44:56.74,Default,,0000,0000,0000,,Here, the running time of this instruction\Ndepends on the operands. Some people
Dialogue: 0,0:44:56.74,0:45:01.53,Default,,0000,0000,0000,,managed to bypass Firefox's same origin\Npolicy with an SVG filter timing attack
Dialogue: 0,0:45:01.53,0:45:08.54,Default,,0000,0000,0000,,with that. There's also the JMP\Ninstructions. So, in modern CPUs you have
Dialogue: 0,0:45:08.54,0:45:14.52,Default,,0000,0000,0000,,branch prediction, and branch target\Nprediction. With that, it's actually been
Dialogue: 0,0:45:14.52,0:45:18.25,Default,,0000,0000,0000,,studied a lot, you can create a covert\Nchannel. You can do side-channel attacks
Dialogue: 0,0:45:18.25,0:45:26.03,Default,,0000,0000,0000,,on crypto. You can also bypass KSLR, and\Nfinally, there are TSX instructions, which
Dialogue: 0,0:45:26.03,0:45:31.01,Default,,0000,0000,0000,,is an extension for hardware transactional\Nmemory support, which has also been used
Dialogue: 0,0:45:31.01,0:45:37.15,Default,,0000,0000,0000,,to bypass KSLR. So, in case you're not\Nsure, KSLR is dead. You have lots of
Dialogue: 0,0:45:37.15,0:45:45.65,Default,,0000,0000,0000,,different things to read. Okay, so, on the\Nconclusion now. So, as you've seen, it's
Dialogue: 0,0:45:45.65,0:45:50.19,Default,,0000,0000,0000,,actually more a problem of CPU design,\Nthan really the instruction sets
Dialogue: 0,0:45:50.19,0:45:55.72,Default,,0000,0000,0000,,architecture. The thing is that all these\Nissues are really hard to patch. They
Dialogue: 0,0:45:55.72,0:45:59.97,Default,,0000,0000,0000,,are all linked to performance\Noptimizations, and we are not getting rid
Dialogue: 0,0:45:59.97,0:46:03.89,Default,,0000,0000,0000,,of performance optimization. That's\Nbasically a trade-off between performance
Dialogue: 0,0:46:03.89,0:46:11.53,Default,,0000,0000,0000,,and security, and performance seems to\Nalways win. There has been some
Dialogue: 0,0:46:11.53,0:46:20.92,Default,,0000,0000,0000,,propositions to... against cache attacks,\Nto... let's say remove the CLFLUSH
Dialogue: 0,0:46:20.92,0:46:26.64,Default,,0000,0000,0000,,instructions. The thing is that all these\Nquick fix won't work, because we always
Dialogue: 0,0:46:26.64,0:46:31.45,Default,,0000,0000,0000,,find new ways to do the same thing without\Nthese precise instructions and also, we
Dialogue: 0,0:46:31.45,0:46:37.41,Default,,0000,0000,0000,,keep finding new instruction that leak\Ninformation. So, it's really, let's say
Dialogue: 0,0:46:37.41,0:46:43.74,Default,,0000,0000,0000,,quite a big topic that we have to fix\Nthis. So, thank you very much for your
Dialogue: 0,0:46:43.74,0:46:47.05,Default,,0000,0000,0000,,attention. If you have any questions we'd\Nbe happy to answer them.
Dialogue: 0,0:46:47.05,0:46:52.73,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:46:52.73,0:47:01.51,Default,,0000,0000,0000,,{\i1}applause{\i0}\NHerald: Okay. Thank you very much again
Dialogue: 0,0:47:01.51,0:47:06.57,Default,,0000,0000,0000,,for your talk, and now we will have a Q&A,\Nand we have, I think, about 15 minutes, so
Dialogue: 0,0:47:06.57,0:47:11.33,Default,,0000,0000,0000,,you can start lining up behind the\Nmicrophones. They are in the gangways in
Dialogue: 0,0:47:11.33,0:47:18.13,Default,,0000,0000,0000,,the middle. Except, I think that one...\Noh, no, it's back up, so it will work. And
Dialogue: 0,0:47:18.13,0:47:22.18,Default,,0000,0000,0000,,while we wait, I think we will take\Nquestions from our signal angel, if there
Dialogue: 0,0:47:22.18,0:47:28.81,Default,,0000,0000,0000,,are any. Okay, there aren't any, so...\Nmicrophone questions. I think, you in
Dialogue: 0,0:47:28.81,0:47:33.44,Default,,0000,0000,0000,,front.\NMicrophone: Hi. Can you hear me?
Dialogue: 0,0:47:33.44,0:47:40.05,Default,,0000,0000,0000,,Herald: Try again.\NMicrophone: Okay. Can you hear me now?
Dialogue: 0,0:47:40.05,0:47:46.48,Default,,0000,0000,0000,,Okay. Yeah, I'd like to know what exactly\Nwas your stealthiness metric? Was it that
Dialogue: 0,0:47:46.48,0:47:51.31,Default,,0000,0000,0000,,you can't distinguish it from a normal\Nprocess, or...?
Dialogue: 0,0:47:51.31,0:47:56.50,Default,,0000,0000,0000,,CM: So...\NHerald: Wait a second. We have still Q&A,
Dialogue: 0,0:47:56.50,0:47:59.78,Default,,0000,0000,0000,,so could you quiet down a bit? That would\Nbe nice.
Dialogue: 0,0:47:59.78,0:48:08.18,Default,,0000,0000,0000,,CM: So, the question was about the\Nstealthiness metric. Basically, we use the
Dialogue: 0,0:48:08.18,0:48:14.32,Default,,0000,0000,0000,,metric with cache misses and cache\Nreferences, normalized by the instructions
Dialogue: 0,0:48:14.32,0:48:21.08,Default,,0000,0000,0000,,TLB events, and we\Njust found the threshold under which
Dialogue: 0,0:48:21.08,0:48:25.82,Default,,0000,0000,0000,,pretty much every benign application was\Nbelow this, and rowhammer and cache
Dialogue: 0,0:48:25.82,0:48:30.52,Default,,0000,0000,0000,,attacks were after that. So we fixed the\Nthreshold, basically.
Dialogue: 0,0:48:30.52,0:48:35.52,Default,,0000,0000,0000,,H: That microphone.\NMicrophone: Hello. Thanks for your talk.
Dialogue: 0,0:48:35.52,0:48:42.76,Default,,0000,0000,0000,,It was great. First question: Did you\Ninform Intel before doing this talk?
Dialogue: 0,0:48:42.76,0:48:47.52,Default,,0000,0000,0000,,CM: Nope.\NMicrophone: Okay. The second question:
Dialogue: 0,0:48:47.52,0:48:51.05,Default,,0000,0000,0000,,What's your future plans?\NCM: Sorry?
Dialogue: 0,0:48:51.05,0:48:55.78,Default,,0000,0000,0000,,M: What's your future plans?\NCM: Ah, future plans. Well, what I did,
Dialogue: 0,0:48:55.78,0:49:01.22,Default,,0000,0000,0000,,that is interesting, is that we keep\Nfinding these more or less by accident, or
Dialogue: 0,0:49:01.22,0:49:06.44,Default,,0000,0000,0000,,manually, so having a good idea of what's\Nthe attack surface here would be a good
Dialogue: 0,0:49:06.44,0:49:10.05,Default,,0000,0000,0000,,thing, and doing that automatically would\Nbe even better.
Dialogue: 0,0:49:10.05,0:49:14.17,Default,,0000,0000,0000,,M: Great, thanks.\NH: Okay, the microphone in the back,
Dialogue: 0,0:49:14.17,0:49:18.77,Default,,0000,0000,0000,,over there. The guy in white.\NM: Hi. One question. If you have,
Dialogue: 0,0:49:18.77,0:49:24.41,Default,,0000,0000,0000,,like, a demon, that randomly invalidates\Nsome cache lines, would that be a better
Dialogue: 0,0:49:24.41,0:49:31.12,Default,,0000,0000,0000,,countermeasure than disabling the caches?\NML: What was the question?
Dialogue: 0,0:49:31.12,0:49:39.58,Default,,0000,0000,0000,,CM: If invalidating cache lines would be\Nbetter than disabling the whole cache. So,
Dialogue: 0,0:49:39.58,0:49:42.68,Default,,0000,0000,0000,,I'm...\NML: If you know which cache lines have
Dialogue: 0,0:49:42.68,0:49:47.30,Default,,0000,0000,0000,,been accessed by the process, you can\Ninvalidate those cache lines before you
Dialogue: 0,0:49:47.30,0:49:52.82,Default,,0000,0000,0000,,swap those processes, but it's also a\Ntrade-off between performance. Like, you
Dialogue: 0,0:49:52.82,0:49:57.94,Default,,0000,0000,0000,,can also, if you switch processes, flush\Nthe whole cache, and then it's empty, and
Dialogue: 0,0:49:57.94,0:50:01.90,Default,,0000,0000,0000,,then you don't see any activity anymore,\Nbut there's also the trade-off of
Dialogue: 0,0:50:01.90,0:50:07.51,Default,,0000,0000,0000,,performance with this.\NM: Okay, maybe a second question. If you,
Dialogue: 0,0:50:07.51,0:50:12.24,Default,,0000,0000,0000,,there are some ARM architectures\Nthat have random cache line invalidations.
Dialogue: 0,0:50:12.24,0:50:16.01,Default,,0000,0000,0000,,Did you try those, if you can see a\N[unintelligible] channel there.
Dialogue: 0,0:50:16.01,0:50:21.96,Default,,0000,0000,0000,,ML: If they're truly random, but probably\Nyou just have to make more measurements
Dialogue: 0,0:50:21.96,0:50:27.18,Default,,0000,0000,0000,,and more measurements, and then you can\Naverage out the noise, and then you can do
Dialogue: 0,0:50:27.18,0:50:30.35,Default,,0000,0000,0000,,these attacks again. It's like, with prime\Nand probe, where you need more
Dialogue: 0,0:50:30.35,0:50:34.08,Default,,0000,0000,0000,,measurements, because it's much more\Nnoisy, so in the end you will just need
Dialogue: 0,0:50:34.08,0:50:37.87,Default,,0000,0000,0000,,much more measurements.\NCM: So, on ARM, it's supposed to be pretty
Dialogue: 0,0:50:37.87,0:50:43.26,Default,,0000,0000,0000,,random. At least it's in the manual, but\Nwe actually found nice ways to evict cache
Dialogue: 0,0:50:43.26,0:50:47.23,Default,,0000,0000,0000,,lines, that we really wanted to evict, so\Nit's not actually that pseudo-random.
Dialogue: 0,0:50:47.23,0:50:51.96,Default,,0000,0000,0000,,So, even... let's say, if something is\Ntruly random, it might be nice, but then
Dialogue: 0,0:50:51.96,0:50:57.17,Default,,0000,0000,0000,,it's also quite complicated to implement.\NI mean, you probably don't want a random
Dialogue: 0,0:50:57.17,0:51:01.48,Default,,0000,0000,0000,,number generator just for the cache.\NM: Okay. Thanks.
Dialogue: 0,0:51:01.48,0:51:05.98,Default,,0000,0000,0000,,H: Okay, and then the three guys here on\Nthe microphone in the front.
Dialogue: 0,0:51:05.98,0:51:13.45,Default,,0000,0000,0000,,M: My question is about a detail with the\Nkeylogger. You could distinguish between
Dialogue: 0,0:51:13.45,0:51:18.15,Default,,0000,0000,0000,,space, backspace and alphabet, which is\Nquite interesting. But could you also
Dialogue: 0,0:51:18.15,0:51:22.32,Default,,0000,0000,0000,,figure out the specific keys that were\Npressed, and if so, how?
Dialogue: 0,0:51:22.32,0:51:25.65,Default,,0000,0000,0000,,ML: Yeah, that depends on the\Nimplementation of the keyboard. But what
Dialogue: 0,0:51:25.65,0:51:29.31,Default,,0000,0000,0000,,we did, we used the Android stock\Nkeyboard, which is shipped with the
Dialogue: 0,0:51:29.31,0:51:34.52,Default,,0000,0000,0000,,Samsung, so it's pre-installed. And if you\Nhave a table somewhere in your code, which
Dialogue: 0,0:51:34.52,0:51:39.54,Default,,0000,0000,0000,,says "Okay, if you press this exact\Nlocation or this image, it's an A or it's
Dialogue: 0,0:51:39.54,0:51:44.45,Default,,0000,0000,0000,,an B", then you can also do a more\Nsophisticated attack. So, if you find any
Dialogue: 0,0:51:44.45,0:51:49.05,Default,,0000,0000,0000,,functions or data in the code, which\Ndirectly tells you "Okay, this is this
Dialogue: 0,0:51:49.05,0:51:54.52,Default,,0000,0000,0000,,character," you can also spy on the actual\Nkey characters on the keyboard.
Dialogue: 0,0:51:54.52,0:52:02.90,Default,,0000,0000,0000,,M: Thank you.\NM: Hi. Thank you for your talk. My first
Dialogue: 0,0:52:02.90,0:52:08.57,Default,,0000,0000,0000,,question is: What can we actually do now,\Nto mitigate this kind of attack? By, for
Dialogue: 0,0:52:08.57,0:52:11.98,Default,,0000,0000,0000,,example switching off TSX or using ECC\NRAM.
Dialogue: 0,0:52:11.98,0:52:17.41,Default,,0000,0000,0000,,CM: So, I think the very important thing\Nto protect would be, like crypto, and the
Dialogue: 0,0:52:17.41,0:52:20.84,Default,,0000,0000,0000,,good thing is that today we know how to\Nbuild crypto that is resistant to side-
Dialogue: 0,0:52:20.84,0:52:24.49,Default,,0000,0000,0000,,channel attacks. So the good thing would\Nbe to stop improving implementation that
Dialogue: 0,0:52:24.49,0:52:31.36,Default,,0000,0000,0000,,are known to be vulnerable for 10 years.\NThen things like keystrokes is way harder
Dialogue: 0,0:52:31.36,0:52:36.83,Default,,0000,0000,0000,,to protect, so let's say crypto is\Nmanageable; the whole system is clearly
Dialogue: 0,0:52:36.83,0:52:41.49,Default,,0000,0000,0000,,another problem. And you can have\Ndifferent types of countermeasure on the
Dialogue: 0,0:52:41.49,0:52:45.78,Default,,0000,0000,0000,,hardware side but it does would mean that\NIntel an ARM actually want to fix that,
Dialogue: 0,0:52:45.78,0:52:48.56,Default,,0000,0000,0000,,and that they know how to fix that. I\Ndon't even know how to fix that in
Dialogue: 0,0:52:48.56,0:52:55.50,Default,,0000,0000,0000,,hardware. Then on the system side, if you\Nprevent some kind of memory sharing, you
Dialogue: 0,0:52:55.50,0:52:58.54,Default,,0000,0000,0000,,don't have flush involved anymore\Nand primum (?) probably is much more
Dialogue: 0,0:52:58.54,0:53:04.88,Default,,0000,0000,0000,,noisier, so it would be an improvement.\NM: Thank you.
Dialogue: 0,0:53:04.88,0:53:11.88,Default,,0000,0000,0000,,H: Do we have signal angel questions? No.\NOK, then more microphone.
Dialogue: 0,0:53:11.88,0:53:16.63,Default,,0000,0000,0000,,M: Hi, thank you. I wanted to ask about\Nthe way you establish the side-channel
Dialogue: 0,0:53:16.63,0:53:23.28,Default,,0000,0000,0000,,between the two processors, because it\Nwould obviously have to be timed in a way to
Dialogue: 0,0:53:23.28,0:53:28.51,Default,,0000,0000,0000,,transmit information between one process\Nto the other. Is there anywhere that you
Dialogue: 0,0:53:28.51,0:53:32.97,Default,,0000,0000,0000,,documented the whole? You know, it's\Nactually almost like the seven layers or
Dialogue: 0,0:53:32.97,0:53:36.58,Default,,0000,0000,0000,,something like that. There are any ways\Nthat you documented that? It would be
Dialogue: 0,0:53:36.58,0:53:40.26,Default,,0000,0000,0000,,really interesting to know how it worked.\NML: You can find this information in the
Dialogue: 0,0:53:40.26,0:53:46.12,Default,,0000,0000,0000,,paper because there are several papers on\Ncovered channels using that, so the NDSS
Dialogue: 0,0:53:46.12,0:53:51.30,Default,,0000,0000,0000,,paper is published in February I guess,\Nbut the Armageddon paper also includes
Dialogue: 0,0:53:51.30,0:53:55.67,Default,,0000,0000,0000,,a cover channel, and you can\Nfind more information about how the
Dialogue: 0,0:53:55.67,0:53:59.32,Default,,0000,0000,0000,,packets look like and how the\Nsynchronization works in the paper.
Dialogue: 0,0:53:59.32,0:54:04.02,Default,,0000,0000,0000,,M: Thank you.\NH: One last question?
Dialogue: 0,0:54:04.02,0:54:09.75,Default,,0000,0000,0000,,M: Hi! You mentioned that you used Osvik's\Nattack for the AES side-channel attack.
Dialogue: 0,0:54:09.75,0:54:17.35,Default,,0000,0000,0000,,Did you solve the AES round detection and\Nis it different to some scheduler
Dialogue: 0,0:54:17.35,0:54:21.44,Default,,0000,0000,0000,,manipulation?\NCM: So on this one I think we only did
Dialogue: 0,0:54:21.44,0:54:24.28,Default,,0000,0000,0000,,some synchronous attack, so we already\Nknew when
Dialogue: 0,0:54:24.28,0:54:27.77,Default,,0000,0000,0000,,the victim is going to be scheduled and\Nwe didn't have anything to do with
Dialogue: 0,0:54:27.77,0:54:32.93,Default,,0000,0000,0000,,schedulers.\NM: Alright, thank you.
Dialogue: 0,0:54:32.93,0:54:37.14,Default,,0000,0000,0000,,H: Are there any more questions? No, I\Ndon't see anyone. Then, thank you very
Dialogue: 0,0:54:37.14,0:54:39.13,Default,,0000,0000,0000,,much again to our speakers.
Dialogue: 0,0:54:39.13,0:54:42.16,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:54:42.16,0:54:58.97,Default,,0000,0000,0000,,{\i1}music{\i0}
Dialogue: 0,0:54:58.97,0:55:06.00,Default,,0000,0000,0000,,subtitles created by c3subtitles.de\Nin the year 2020. Join, and help us!