
thank you very much for your patience this is our last talk for today but do hang around for some for the closing at the end which is only just a minute or two there'll be a party of varying lane behind reload bar tonight at 7:00 p.m. but buses leave at 6:15 p.m. and in fact all organize the buses so thanks very much to Paul to getting us to Verity Lane and in a nice and easy manner there are two loops actually the buses so if you don't catch the first set of buses there's three buses coming at a time just hang around and there's a second second round of buses as well the CTF will close down tonight at 5:30 p.m. and
resume again tomorrow at 9:00 for the I our charge continue working on it overnight and and see how you go right now when you have one of our hosts and staff for the hardware hacking knowledge doing a talk on micro architectural attacks and reflecting on 45 years of research since a note on the confinement problem so let's welcome Paul Harvey to the stage [Applause] thanks for thanks for waiting my technology isn't very happy today I'm a electronics person who largely didn't find much work doing electronics in Australia so I do software for most of my career I do open source stuff usually with open software open source and this talk is kind of you know we flock from
the next shiny thing from one next to anything to the next and this is sort of just taking a few minutes to reflect on where we've come from what what are the problems that we're solving and where are we going next how can you tell if you're going in circles if you don't know where you've come from so today it's mostly a sort of haze of PDFs and a lot of PDFs it's not really original research what I'm showing here it's just some stuff that I thought is interesting side-channel attacks and micro architectural attacks turn out they go back a long way how many of us here today would you put your hand up if you think you're a builder or
you work more on making stuff than breaking stuff yeah few of us we sort of we sort of I think as builders we kind of get comfortable in where we are in our stack I know some of us pretend that we're full stack I don't even know what that means like I don't know what cloud means really or agile and it's it's interesting to think about abstraction layers there are some really great works on talking about how to classify vulnerabilities and what properties each kinds of vulnerability in a classification system have and an interesting one is Bishop from 1999 here he talks about the confusion that there is in traditional taxonomy as for bugs it's hard to put bugs into one but this
was back in the 90s of course so one of the observations he found was where you are in there in the abstraction layers counts it for context when you're when you're thinking about bugs this is this next paper holographic vulnerabilities it's talking about data flows across interface boundaries and across abstraction layers and they they're able to express most bugs in these terms they think I don't necessarily agree with all of these papers by the way they're just they're just talking about interesting stuff so the the helva down the bottom there said it succinctly and it's basically in security lives and breathes in the cracks between abstraction layers this is a this is a Graff from one of the papers that my
talk is focusing on the hardware stuff obviously this is a plot of my of a portion of my papers database if you don't use a papers database program I highly recommend Zotero it's pretty cool there's something called the mask AB they're micro architectural attacks side channel attack be blog Rafi and it has 137 references going back to 1974 and there's an additional hundred ish items that are in there and this top pane this top pane is showing about 16 years worth of research it's been pretty busy since the year 2000 just for some context back in the 1960s computers cost the best part of 20 million dollars in 2017 money and IBM had a relationship with MIT that
they would get a newish model of mainframe as they became available because MIT were good at putting him to work and finding you know fun stuff to do with them and that helps develop their business one of the interesting things about this though was IBM demanded some control of these donated machines and one of the example jobs that they had to run at the drop of the Hat was the IBM CEOs yacht handicapping program so when he was figuring out what handicaps the yachts and in the yacht races should have they had to stop this twenty million dollar machine and make it run the CEOs job and then they could go back to doing real work in coping
with that context which changing jobs midstream because these were batch machines they're sort of glorified graphics calculators that wasn't quite a refined thing at that time and I'll just talk about in a minute what really enabled multi-user you know the having more than one thing running at a time on a machine this this switching to the CEOs job and back kind of had it sort of accelerated the development at MIT for forgetting context which in going basically and they they had context switching on the order of minutes to hours but it was it was possible you could interrupt a job and restore it when he came back and that was a big deal at the time so 72
years ago so in World War 2 electrical engineers said let there be batch programming and things kind of weren't very friendly for a long time these were big scary machines you needed expensive operators to run them in 1941 the Germans made the z3 in 1944 the US Navy made the mark 1 and any act which is the public first computer public you know non-classified computer was 1946 and sigh rack was 1949 in nineteen in those years I was thirty years away so there was no good text editors in any time soon so they started dreaming about time sharing and not not having to have one person at a time and this this man John Backus he's likely to be in B and F if
you know what that is Backus normal form oh sorry
see TSS was the compatible time sharing system this was a precursor to something called multix how many of you have heard of Maltese are good it turns out mold is multics made a big mark on on computer security at the time and CT SS was a precursor and they sort of bootstrapped mortix with CT SS and they didn't they were dreaming about this this multi-user stuff for a good long while before they actually got it john mccarthy who invented lisp of course actually started butchering one of these very expensive machines in IBM 704 to have interrupts so the IBM 74 they had didn't have interrupts and that made the possibility of developing time sharing very
difficult so he sort of was pulling it apart in Seoul during in relays and valves and stuff and it made IVM moderately upset because it was technically at least a machine and in the end they convinced them to sell the a customization option that Boeing had for real-time work with wind tunnels and that actually had an interrupted feature that was actually not an official sort of a catalog item but it was something that IBM had developed for Boeing and they were able to use it in the 74 ran off valves so the first transistorized machine was actually the 1790 which is what multix ran on sorry it was a transistorized machine multics started at the outset to securely run
multiple users data some control data access in a really tight way that could satisfy government requirements not from the very beginning but very soon after its beginnings the US government wanted to do this as sort of I think as a cost-saving exercise because the machines were so expensive they wanted a way to share the resources between different classification levels and different compartments within classification levels mm-hmm and they eventually did achieve the orange book b2 rating which took a very long time and then they killed it shortly after to achieved certification which is a bit tragic so mm-hmm they learnt some things from this security through obscurity doesn't work also counting on attackers to be lazy doesn't work penetrate and patch
doesn't work this was like in 1970 they'd figured that out security has to be formally defined relative to a policy model and they need implementations that have formally verified and formal verification techniques were developed at the time we had IBM's Vienna development method and there was also the Z proof checker so they had this proof checking like really advanced stuff that's sort of coming back into vogue a little bit now with functional programming it has its origins back in the 70s this is one of my favorite slides has anyone heard of the ware report no one yes one person the ware report was 1970 and they were thinking about as you can see in the picture here
all different kinds of threats on shared computers they
in in this in this next slides I have stuff from DoD's computer Security Initiative program these were seminars held with in the aftermath of multix kind of in any other efforts they had multix wasn't the only one but we don't have time to talk about the others today they spent a lot of money a staggering amount of money hundreds of millions of dollars trying to get secure systems and they didn't want to keep doing that forever so they really wanted to try and get the private sector on board for building secure systems and maybe get some off-the-shelf secure stuff one day wouldn't that be nice they're still waiting I think but some of the stuff they were
thinking about was as you can see the cpu features did by the way hackers Technicolor rainbow stuff incidentally package was released in 1995 Common Criteria version one was published four drafts in January 1996 just thought I'd throw that out there there's something called the program status word in IBM 360 main friends and this is kind of interesting they talk about a key which protects programs it protects the memory manager meant the MMU from being able to access memory when you're in the context of a given program it's kind of it feels a little bit like Intel MPX or maybe with the multics Hardware actually they had pointed cross ring pointed reference checks so if a high privilege if a low
privileged domain tried to dereference a pointer that was minted in a in a more privileged ring that would generate a fault which kind of reminds me a little bit about authenticated pointers it's not really the same thing but so we had some admissions here in 1979 about the fact that they weren't really achieving outcomes they wanted they had to revert to traditional techniques and traditional techniques for secure for maintaining security isolation back then was basically turn off the giant mainframe plug in some different hard drives and start the next shift for the next classification level if you wanted to do that but I think the other thing that was happening at that time was multics was from the 60s and it was
solving a 60s problem by the time the 70s had come around computers were getting you know not ridiculously cheap but they were cheap enough that you could have one in each office and they didn't really have such an urgent need to spend hundreds of millions of dollars to get secure isolation between users you could just buy another PDP and another PDP machine and just just buy more hard way hardware and solve it that way
some examples of penetrations that they experienced back in the early 70s os/360 had supervisor calls that were not adequately protected there was G costs checkpoint dumps not restricted I think that's kind of like a core dump that imagine its world readable and that would be bad this one down the bottom here misuse of i/o processor that's kind of like your modern-day DMA attacks they had different little CPUs off to the side of these big things to to speed up i/o and you could program them with additional software
okay
so the lessons learned unfortunately something Horrible's happened
so I'll just wing it and know from the confinement problem was was pretty cool in 1973 they found side channels where you could have notionally different isolated processes sharing information between each other using IPC files and home directories these seem kind of obvious now but they weren't really thinking about things systematically sometimes when you know when the end users were putting together and their information systems exfiltration by billing if I was really exciting they thought like if they're billing by the minute of how much CPU or what utilization the hardware has you know you could modulate the the load on the system to sort of get some data extra laps through your three invoices probably a low bit rate and of course
this one here varying its ratio you know processors can virtually monitor the system load and communicate that way so we have this one from 1995 leaked via registers when context switching so there's stuff like the segment registers weren't often cleaned up in those days when you know things like Windows were running if he is kind of difficult to to sanitize every time in context which it's kind of expensive so you can leak some information if the FPU is in an exception state you can do some timing analysis there to communicate between processors high resolution timers are a common thing throughout the literature back to the 70s as well and I'll get to that one so I find it very interesting that
Firefox in 2015 had a vulnerability from the spy in the sandbox paper which was about using high resolution timers as as part of it's a quotation with
branch prediction stuff so they reduced the resolution down to five microseconds but then in 2018 when the specter meltdown attacks happens they just had to reduce the resolution down to two milliseconds
I don't know how to pronounce the first author's name here so that's kind of embarrassing but he brought some really good stuff and this is kind of a it was studying branch predictors and branch target buffers as as a way of using for side channels initially but then he found his team found that they could also spy on another process by polluting the branch target buffer with sort of like a case case purge and reload attack where they can sort of spy on the state of the branch target buffers and determine which code paths the other process was taking it looks really fiddly to me but these these guys figured it out in 2006 and then a
subsequent paper paper he he really figured it out because he was able to extract RSA secret keys just by spying on a single operation in the last mile they actually measured branch misprediction a side channel 1100 bits per second timing attacks we've known about them for a long time now they seem old hats but in 1996 I think I don't know if this was the actual first paper but it is a very early paper on using timing side channels at all for extracting secret key information row hammer is is a good one we're probably all familiar with so I won't spend too much time on it but basically it involves repeatedly accessing a given row of memory which the memory
controller will happily top-up with charge with the normal schedule recharge cycles unfortunately it drains the neighbor rows as well when you're accessing the same memory dress over and over again it'll drain the neighbor rows charge to such an extent that it and they're not on the refresh schedule basically so you can flip bits by by doing that and there's there's a there is a paper on doing this with NAND flash and SSDs as well so you can sort of flip bits selectively but I haven't even put an actual paper there because I haven't seen one that actually pulls off an attack successfully but maybe there is one so please do feel free to tweet me a
few if you know of one corkscrew is really fun because it's basically failure to identify the power management in a system as part of your trusted computing base TCB is something that security analysts often think about because you need to control you need to be able to trust your TCB it's everything that the CPU and your environment has to be able to trust in order to execute code safely and what they're able to do is have an unprivileged process and manipulate the voltage and affecting the CPU scaling you know in a nexus 6 I think it is such that they can glitch the CPU so when it's in a very sensitive part of some crypto so they're actually able to
extract AES keys not directly but the they'll able to I there's a lot of learning phase happening so when they map out exactly what the timings should be they can target the final round of a SAS has ten rounds I think it's on the eight rounds so on the second final rounds they add they glitch that round and then compare the result with so it's like a known plaintext attack so they they know what the result should have been from that from the trusted zone encryption process that they get a corrupted one back by glitching that final AES round and they're able to use a crypt analysis attack with two to the twelve which is pretty fast and they're
also able to get the trusted zone [Music] in the next Nexus 6 to load some self-signed code which shouldn't be able to do now the category of attack is the non-deterministic timing in in stuff that we don't really think about so this one's like using SVG canvas I think to put a filter on bits of the Dom that a piece of JavaScript shouldn't have privileges to be able to manipulate so like if it's an iframe in a web browser it shouldn't be able to access the parent Dom's Dom nodes but it can map out what color the pixels are by putting an SVG filter over them and timing the differences because it goes into the FPO
and FPS are pretty noisy when it comes to I'm doing graphical stuff so this is just another paper I wanted to share because it's indicative of just how complex x86 is getting this single instruction has so many modes and states that and and features that that we can get a cheering machine out of this one instruction you actually don't have to use other instructions there's a compiler app called MOFA skater if I had my speaker notes I'd be a lot more eloquent I promise but to top that off the the page fault weird machine is probably my favorite it it doesn't actually successfully execute any instructions this is just using the MMU to continuously trap and set up and set
up page faults in a way that does useful computation and there's a C compiler for that as well and I imagine debugging that would be a nightmare it's called trap cc
when meltdown inspector was was going on at the start of the year this guy on Twitter I thought was interesting he said he gave a talk at Intel with with this slide and he was trying to say to Intel it is very likely that out of order execution prefetches intermediate buffers dependence prediction predictors memory controllers and energy management units value predictors all this stuff could lead to attacks not just on cryptography implementations but but non cryptography applications as well and he was completely right so he actually gave Intel this presentation six years ago it obviously wasn't in a part of Intel that could do anything with that information of course so the conclusions are if you
need to share anything with an attacker that's just really hard if you don't have to don't obviously not everyone can afford to do that in the physical realm you know we can limit post expertly it's kind of terrifying that a JavaScript program from an ad can break out and maybe get all the way up to your bare metal so just turn on all the things secure boot especially in the virtual realm there's dedicated hosting offerings and bare metal offerings I think packet dotnet is one such vendor and if we don't have to trust CPUs then just use the T cams and HSM as we have available there's smart cards as well they're all standards-based today a
nightmare to work with but they worth using that's all thank you
do we have any questions of the audience right we'll just give some housekeeping about where to go tonight so the buses should the verity lane party will come at 6:00 - think there'll be two rounds of buses like I said earlier there is a small passing storm currently going on - its but apparently it is only going to be quite quick and it will pass fairly you feel incomplete smoothly so even though it seems like the tornado is going on outside it up over give it 15 1/2 15 minutes or half and actually be okay that's pretty much it thanks for attending the first say I hope you all enjoyed it and we'll see you tomorrow
we'll see you at the party thank you very much [Applause]