Spectre of the £50bn PPI crisis looms large on banking sector

How a car finance ruling is affecting UK banks - The Banker

Spectre

spectre

This article is based on my Linux Performance Monitoring and Tuning course on Pluralsight which, by coincidence, was released just before news of Spectre and Meltdown broke. By now the critical stage of the is largely over. Patches for affected operating systems have been written and, assuming you keep your servers properly updated, you should be safe. Spectre and Meltdown vulnerabilities That’s the easy part. The real problem is that the patch might slow your system down — particularly if you’re running applications that interact often with the kernel. So you’ll want to know just how much of a hit you’ve taken, and what upgrades you’ll need to get you back to where you should be. My discussed understanding, diagnosing, tuning, and monitoring performance on Linux servers. Those are the tools of choice for the kind of assessment and administration this problem demands, so I thought I’d make this guide to installing and using the collectd daemon to gather and monitor performance metrics locally or across a network. recent Pluralsight course Besides collectd, the course also covers the Nagios, Munin, and nmon monitoring tools, along with analysing metrics and optimising existing stacks. Ideally, you would have some older, pre-Spectre, performance data available to use as a baseline. But even if you have to start from scratch, it won’t take too long for collectd to start pointing fingers at your pain points. Installing collectd collectd is a Linux system daemon that collects and organizes system performance data into Round Robin Database (RRD) files normally kept in the /var/lib/collectd/rrd/ directory tree. I’m going to take you through the process of installing and configuring collectd. I’ll then demo a tool called collectd-web that will convert the RRD data into graphs. Once that’s all done, I’ll show you how to set up a couple of remote servers as collectd clients so we can access data from the entire fleet on a single server. But one thing at a time. Installing collectd as a standalone is simple: you need nothing more than the collectd package. Getting the collectd-web tool installed and running, on the other hand, can be a bit of a trick. Since clients require nothing more than collectd, I’ll focus on setting up the machine our collectd server. I’m going to be doing this on an LXC container running Ubuntu 16.04. Here’s the package list. # apt install -y collectd python build-essential \librrds-perl librrds-perl libjson-perl libhtml-parser-perl \apache2 Let me break that down for you. We’ll need Python to run the collectd-web tool and build-essential to build the source code we’ll get later. Those Perl libraries are to interpret the RRD database files and to add JSON and CGI functionality. Finally, we’ll be using Apache as our web server to handle the web requests themselves. I’ll let all that happen by itself and skip the boring details.  Next I’ll use a2enmod to enable the CGI modules that’ll allow Apache to manage some of the visualizations. # a2enmod cgi cgid cpan will install a couple of Perl modules. Make sure you use uppercase for JSON and CGI. # cpan JSON# cpan CGI I’m going to use a text editor to add a section to the 000-default.conf file in the /etc/apache2/sites-available/ directory that will enable Apache CGI script handling from the web server end. <Directory /var/www/html/collectd-web/cgi-bin>Options Indexes ExecCGIAllowOverride AllAddHandler cgi-script .cgiRequire all granted</Directory> With that done, there’ll be only one more thing to do get Apache just the way we want it. Take a look at the apache2.conf configuration file and scroll down to the Include line where we set the network ports on which to listen. Note how it’s all offloaded to a file called ports.conf. # Include list of ports to listen onInclude ports.conf If we want to be able to access our data remotely through a browser, that’s the file we want to edit. I’ll just make sure the “Listen” line in ports.conf reads 0.0.0.0:80, so that we’re not restricted to only local guests. Listen 0.0.0.0:80 With all our Apache work done, now’s the time to restart it so everything is properly updated. # systemctl restart apache2 Now we should take a quick look at the collectd.conf configuration file in the /etc/collectd/ directory. It’s a big file and most of the default settings will work for us right now, but you should be aware of the kinds of things you can add and how they’re configured. Most of collectd’s power is delivered through its plugins, which you load (by uncommenting) in the LoadPlugin section. Some of the plugins might already be loaded, like apache and cpu near the top. LoadPlugin apache#LoadPlugin apcups#LoadPlugin ascent[…]LoadPlugin cpu This means that, when properly configured below, collectd will monitor and report Apache and CPU behavior. You’ll also need to configure each of your plugins below in the configuration section. The cpu configuration is commented out, but it will work fine with its default values. In this case, the configuration section is only for people who might want to customize it. #<Plugin cpu># ReportByCpu true# ReportByState true# ValuesPercentage false#</Plugin> If you do edit the config file, be sure to restart the daemon using systemctl. This is also a good place to look for error messages in case something went wrong. Pay close attention to any error messages you get — especially through the system logs — and carefully check the syntax you used in the configuration file. It’s also possible that you’re missing a Perl module or two. # systemctl restart collectd# systemctl status collectd But before all this will be useful, we’ll need to install the collectd-web tool itself. I’ll first install git, and then clone the collectd-web repository. This will save the source code to a new directory called collectd-web. # apt install git$ git clone https://github.com/httpdss/collectd-web.git There’s a script in the cgi-bin subdirectory that we’ll have to make executable, so I’ll change to cgi-bin and use chmod to add an executable bit to graphdefs.cgi. Then I’ll head back one level to the collectd-web directory so I can make one edit to the Python runserver script. $ cd collectd-web/cgi-bin$ chmod +x graphdefs.cgi$ cd ..$ nano runserver.py I’m going to change the two places where the localhost is referenced by 127.0.0.1, and open them up to the entire internet by editing them to read 0.0.0.0. This will allow collectd to listen for data from other machines. With that, we’re all set. Make sure you’re in the collectd-web directory, and run the runserver.py script. I’ll add the ampersand character so it’ll run in the background and I’ll get my command line back. It’s a good idea to keep an eye on this shell, however, since events are printed here that can sometimes be useful. $ ./runserver.py & Now I’ll fire up a browser and point it to the LXC container’s IP address, specifying the port 8888. Speaking of network ports, if you’re running a firewall, you’ll need to open up ports 8888 and 25826. You can click on the name of your host and then select from the metrics displayed below. The CPU display for the local machine (called collectd) A multi-host collectd configuration If you’ve been following along with the demo so far you’ve got metrics from a single server being displayed through a local web service. But if you’ve got lots of servers, you probably won’t enjoy opening a new browser tab for each one — especially not if you’re expected to cycle through them periodically through your work day. So why not send the data to a single server? Let’s do that. I’ve launched two servers and installed nothing more than the collectd package on each. Their hostnames are collectd-client1 and collectd-client2 — which will make it easier to identify them later. I’m logged into one of my clients and I’m going to edit the collectd.conf configuration file. At the very least I’ll need to make sure the network plugin is enabled and then head down to the configuration to set things up. All I need to do there is uncomment the open and close Plugin network lines, the open and close Server lines, and then edit the Server IP address to match IP used by my Collectd server. This is so the client can push data to the server. I’ll leave the other lines at their default values. LoadPlugin network <Plugin network># # client setup:# Server “ff18::efc0:4a42” “25826”<Server “10.0.3.102” “25826”># SecurityLevel Encrypt# Username “user”# Password “secret”# Interface “eth0”# ResolveInterval 14400</Server># TimeToLive 128 # # server setup:# Listen “ff18::efc0:4a42” “25826”# <Listen “239.192.74.66” “25826”># SecurityLevel Sign# AuthFile “/etc/collectd/passwd”# Interface “eth0”# </Listen># MaxPacketSize 1452 # # proxy setup (client and server as above):# Forward true # # statistics about the network plugin itself# ReportStats false # # “garbage collection”# CacheFlush 1800</Plugin> That’s it. You’ll restart the collectd service and then repeat the process on any other clients you want to monitor. # systemctl restart collectd Now, back on the server, I’ll edit the same configuration file, and make sure that networking is enabled. Again, as before, I’ll scroll down to the networking configuration section and uncomment the Plugin lines, but this time, I’ll uncomment and edit the Server Setup section rather than the Client section. Here, I’ll change the Listen line to 0.0.0.0 so the server will listen for incoming data from anywhere. # server setup:# Listen “ff18::efc0:4a42” “25826”<Listen “0.0.0.0” “25826”># SecurityLevel Sign# AuthFile “/etc/collectd/passwd”# Interface “eth0”</Listen> I’ll save and close the file and restart both the collectd and apache services. # systemctl restart collectd Then, making sure that the Python runserver script isn’t already running — if it is you should shut it down using kill — start it up again. $ ./runserver.py & Now head back to the browser and refresh the page. Links for each of your clients should immediately appear, allowing us to choose between views. A multi-host configuration. Note links to three hosts in the left panel You might possibly require a server reboot and some luck to make this work the first time. It can be a bit finicky. But you’ll definitely appreciate the results. Interpreting and acting on the results you get is your department, but my Pluralsight Linux Performance Monitoring and Tuning course touches on a lot of what you’ll need to know. Interested in Linux administration in general? There’s lots more where that came from at my Bootstrap IT site, including links to my Manning book, Linux in Action, and a hybrid course called Linux in Motion that’s made up of more than two hours of video and around 40% of the text of Linux in Action.

Cleaning up after Spectre and Meltdown: figuring out how badly they slowed down your servers

The important technical aspects of Spectre and Meltdown In a we discussed the recently disclosed processor attacks called Spectre ( , ) & Meltdown ( ). While we know that most of our readers are users of technology who simply want to be better at security (and aren’t interested in the technical), we also know that some of our readers enjoy going a bit deeper into the technical weeds. In this post we’ll highlight some of the key technical learning that comes from Spectre and and Meltdown. previous post CVE-2017–5753 CVE-2017–5715 CVE-2017–5754 Although this is a technical blog post, this is not meant to teach the attacks. Instead, it highlights some key technical principles that the attacks present. This blog is based on the , and those should be consulted for a full understanding of these attacks. technical write ups Key terminology Before we discuss the what exactly is happening in Spectre and Meltdown we have to understand some key terminology: Side channel A side channel in information security is a function or characteristic of a system that discloses unintended information. An example in the physical world: visibility of lights within your home is a side channel for identifying if someone is in your house without actually observing a person in the house. Or if one light comes on every day at the same time and no other lights do, it’s a side channel for identifying that the occupants may be out of town. So a side channel looks out for information that is being disclosed, and attempts to exploit it. A side channel is not necessarily a technical weakness in a specific system. An example of this in technology: noticing heat differences of a computer to deduce what the system is doing. has a good article on this in practice. Wired Covert channel A covert channel is more invasive than a side channel. While a side channel is simply “observed,” a covert channel usually alters the system it’s attacking. This alteration creates the ability to transfer data from a privileged context to a context that should not have access to that data. An example in the physical world: an adversary bugs a house by hiding microphones in your walls. They have altered the house, and can now overhear privileged conversations. An example of this in technology: A malicious program exfiltrates data by , of legitimate packets. The attacker then sniffs these packets off of the network. By encapsulating data within the IP identification field of legitimate packets, a malicious program may be able to bypass system monitoring. modifying the IP identification field In both cases the covert channel causes a “change” to the system, whereas a side-channel is passive. (Note that in common parlance, these terms are sometimes used interchangeably — simply to denote a method of unintended information disclosure). Kernel Operating Systems have a portion designated as the “Kernel”. This is loaded into protected memory spaces and controls the interaction between the programs and the underlying hardware of the system. Virtual memory Computers isolate one process’ memory from other processes’ memory. But each program thinks it has access to all of the system’s memory. The Central Processing Unit (CPU) presents each process with a virtual memory space and maintains a “page table” that translates this virtual memory to physical memory. Physical memory These are the hardware based memory modules that sit physically within your computer and hold the actual bits that make up random access memory (RAM). The CPU maps virtual memory to physical memory. Pipelining, out-of-order/speculative execution, transient instructions The architecture design of modern CPUs led to the Spectre and Meltdown vulnerabilities. Specifically, instruction pipelining. Programs are written in human readable languages (e.g. Python, Ruby, JavaScript) and then into which can be executed by the CPU. compiled machine code To improve efficiency, modern CPUs implement instruction pipelining. This means that the processor tries to keep every part of the CPU occupied with something. So while one part of the CPU is fetching data the CPU may move on to the next instruction, even if it depends on the result of the fetched data. This leads to out-of-order execution of instructions. The CPU make a best guess on what instructions will be executed next. This is also known as speculative execution. If the CPU takes an incorrect logic path the results of the speculative execution are disregarded. These disregarded instructions are known as “transient instructions”. Although these transient instructions do not change actual program flow, during the speculative execution of these transient instructions the “microarchitectural state” of the CPU changes. Specifically, the CPU cache is affected. CPU cache To further speed up access, the CPU maintains on-chip caches that store the values of frequently accessed memory. Race condition A race condition in information security is a vulnerability that requires an attacking system to be the “first” to respond to a data request or the first to access data before it disappears. A good technical example of a race condition was a . Essentially, if an attacker can write files to the system they can overwrite a temporary file that is generated during a privileged MySQL operation. If they replace the temporary file, after file creation but before operation completion, they can escalate privileges to a within MySQL. 2017 vulnerability in MySQL User-space vs kernel-space memory pace Finally, it’s important to make an explicit distinction between kernel-space memory and user-space memory. The user-space virtual memory holds the memory of running programs (i.e. processes). User-space virtual memory is mapped to a specific portion of physical memory. The kernel has its own virtual memory space (We’ll see the consequences of this when we discuss Meltdown). but this kernel-space virtual memory is mapped to the entire physical memory The CPU maintains a page table that includes mappings to kernel-space and to user-space memory. This page table translates virtual memory to physical memory. It’s important to remember that kernel-space memory is mapped to all physical memory, which also contains user-space memory. Virtual memory page table layout, Source: Meltdown paper When switching between user-space operations and kernel-space operations the CPU denotes if the virtual memory in use is user-space virtual memory or kernel-space virtual memory. It does this by setting or unsetting a “supervisor bit”. This limits the memory access of the current CPU operation to specific pages of virtual memory. So with all of these terms defined, let’s look at how Spectre and Meltdown exploit modern CPU architecture design. Isolation not respected The key design flaw, that both of these vulnerabilities take advantage of, is that memory placed in caches is not protected from access by other processes that should not have access to the original, uncached memory. With all of the vulnerabilities, a malicious program causes data to be written to the CPU cache, which is then read through a side channel attack. This side channel attack is dependent on a race condition of the malicious program reading the CPU cache before it is overwritten. Spectre The consequence of Spectre is that an adversarial program can read the process memory of other programs. As we mentioned above, modern CPUs use speculative execution to increase processing efficiency. CPUs take a best guess approach to speculative execution. By observing recent execution patterns the CPU “trains” itself on the fly to follow certain logic paths more often than others. Spectre takes advantage of this design and trains the CPU to follow desired speculative paths. There are two variants of Spectre: conditional branch misprediction exploitation and indirect branch exploitation. Conditional branch misprediction exploitation One of the powerful aspects of programming is the ability to write conditional logic. i.e. “if this then that”. This gets translated into “conditional branch” logic at a machine code level. To exploit Spectre, a malicious program performs conditional tests with the same result, or , repeatedly. true false Pseudocode for a conditional branch operation: x = 6if x equals 6print 'x equals 6' If we perform the above action repeatedly the CPU will train itself to follow the path during speculative execution even if the result is not true in a later operation. true Now let’s say during a later speculative branch operation we try to access privileged memory x = 2if x equals 6y = my_array[x * 256]  ; memory outside of the current program The conditional test will fail. The processor will look up the value at the memory address of array which is 512 bytes ahead of in memory, outside of the programs memory space. But if we’ve properly trained the CPU, before it fails the test, the CPU will perform the transient instructions of the **true** conditional branch . my_array[x * 256] my_array If the conditional branch actually evaluated to true this would cause a memory access violation error to be thrown and the program would crash. But it the conditional evaluates to , no error is thrown and the result of the transient instruction is disregarded, but the result of the transient instruction (the value at ) now sits in the CPU cache. false my_array[x * 256] Indirect branch exploitation Indirect branch machine code instructions cause the CPU to evaluate machine code instructions elsewhere in memory instead of continuing the sequential processing of instructions. Example machine code operation jumping to execute instructions at memory address : 0x12345678 jmp 0x12345678 If a malicious program can train the CPU to take speculative jumps to code that performs known computation, this computation can change the microarchitectural state of the CPU cache. The key similarity between conditional branch misprediction exploitation and indirect branch exploitation is that both methods train the CPU to take a speculative logic path that results in execution desired by the exploiting program. It is is eventually disregarded, but before this discard happens, it alters the CPU cache. The key difference between the two is the location of the machine code. The code of conditional branch misprediction exploitation sits within the malicious program’s memory space. On the other hand, the code of indirect branch exploitation sits elsewhere in memory but still performs the desired computation that alters the CPU cache. Harvesting data from CPU caches The CPU cache is then used by the malicious program as a side channel. After either conditional branch misprediction exploitation or indirect branch exploitation the malicious program performs time based side-channel attacks to infer what changes were made to the caches, subsequently learning the privileged information stored in these caches. These attacks are documented in other research and are outside of the scope of this blog post. So as a full attack process, Spectre uses CPU caches to create a covert channel that moves the data from one process, within user-space memory, to a malicious program, also in user-space memory. In the end, Spectre discloses privileged information to a malicious program. In contrast to the two Spectre vulnerabilities, the Meltdown attack has a single variant. It also uses the CPU cache as a covert channel, but with some important differences in how the attack is technically carried out. Meltdown The consequence of Meltdown is that a malicious program can read kernel-space memory. Since kernel-space memory is mapped to all physical memory this means that a malicious program can read all kernel-space memory and all user-space memory. Meltdown is an attack tailored to the logic circuitry of the CPU, and for this reason it is mainly limited to Intel-based processors. Meltdown does not require code that is tailored to a specific software environment. With Spectre, by comparison, attacks must be tailored to the software environment of the victim’s system — but they can work on systems running Intel and non-Intel architecture. Additionally, the Meltdown attack abuses a privilege escalation vulnerability: Intel CPUs allow the transient instructions of user-space processes to access kernel-space memory. Exploitation Instead of training the CPU to take specific logic branches, Meltdown directly attempts to access privileged kernel-space memory pages. When a user-space process attempts to access privileged kernel-space memory the CPU throws an access violation exception error. The malicious program “ ” the access violation exception. By catching this exception the malicious program doesn’t crash. However, the CPU still executes the transient instruction and kernel-space memory is placed in the CPU cache. catches The malicious program then performs the same side channel attacks that Spectre uses to read CPU cache memory. With these two classes of attacks, there are different steps for mitigation. Mitigation Let’s look at the technical solutions for Spectre and Meltdown. Meltdown migitagion Meltdown is the easier of the two to mitigate. Some patches have already mitigated Meltdown. Meltdown depends on accessing kernel-space memory, and because that memory is already designated as privileged, the CPU simply needs to respect this isolation when executing speculative instructions. In June of 2017, before these vulnerabilities were disclosed, the Linux kernel implemented a patch called Kernel Address Isolation to have Side-channels Efficiently Removed (KAISER), to prevent the disclosure of random kernel-space memory via side channels. KAISER separated the kernel-space page table and the user-space page tables completely. With KAISER, the kernel-space page table is only available when performing kernel operations. The goal of Meltdown is to go from random kernel-space memory access to systematic kernel-space memory access. Since the malicious program runs in user-space memory, and no longer has access to the kernel-space page table, the KAISER patch inadvertently mitigated Meltdown. Mac and Microsoft are both implementing their own versions of KAISER which are generally known as Kernel Table Page Isolation (KPTI). Spectre mitigation Unfortunately, Spectre will probably “haunt” us for a long time. This is because attacks are happening within the same memory space (i.e. user-space memory), and it is hard to isolate memory access during speculative execution. Researchers propose several possible steps for mitigation: 1) halting potentially sensitive speculative execution paths until earlier logic is resolved, and 2) flushing branch prediction models when switching between processes. The first solution would “severely degrade performance” and we’ve already seen benchmark performance take hits of 2%-14% with the patches provided at the time of writing this post. The second solution is currently stated as a hypothetical in the research, and the authors acknowledge that it may not mitigate all cases of Spectre. Conclusion These are by no means easy vulnerabilities to understand. They delve deep into the core workings of CPUs and blur the lines between software and hardware. In addition to understanding everything written here, to perform the attacks, you would also have to understand the previous literature that details how to perform side channel attacks against CPU caches, which we take for granted here. (This is mainly because I don’t fully understand how to implement them on a level deeper than the theoretical). I hope that this has helped you understand the deeper, technical aspects of these vulnerabilities. I myself am constantly learning, so if you notice a technical inaccuracy please leave a comment! This is a post from Isaiah Sarju of Revis Solutions . If you like this post be sure to clap, check out his other posts on the Revis Solutions Blog , and follow on Twitter @isaiahsarju , @revissolution

Spectre & Meltdown Processor Vulnerabilities: A Technical Introduction

There’s never just one or two isolated, one-off flaws in complex computing products. Especially with a product as complex and widely used as Intel CPUs, once one vulnerability is exposed, many more will soon follow. security Throughout the 1990s and into the 2000s, Microsoft spent years playing whackamole in an arms race against malware. At the time, security was seen by most software companies as a step in the pre-release quality assurance process, if that. When problems were found after a release, they were fixed in subsequent updates, as part of a scheduled release cycle. That strategy failed Microsoft in the 1990s. Facing mounting concerns from consumers and a possible rebellion among its business customers, Microsoft and other firms trained their engineers with new skills, redesigned their products with security-focused frameworks, enacted transparency policies to keep users informed, and developed infrastructure to quickly roll-out fixes. Today, while malware attacks are more clever and pernicious than ever, Microsoft has mostly stemmed the tide of newly infected Windows computers. With Windows computers becoming harder and harder to penetrate, hackers have reason to seek new targets. Low-level hardware has been long overlooked as a ripe attack surface for intruders — a mistake Internet criminals will soon correct. The good news is, chips from Intel and its competitors are far more carefully engineered than Windows ever was. Regrettably, that’s the extent of the good news. Intel does not appear to have a healthy culture around security. Even if it did, at a technical level, any hardware manufacturer faces unavoidable challenges guaranteeing the ongoing safety of its products once problems are found. As software giants evolved to defend their customers against a treacherous Internet, a few best practices emerged for responding to security vulnerabilities and incidents. Tenants of and have been part of the culture shift toward dealing with security effectively and fairly. accountability, transparency, continuous improvement On the transparency front, Intel published (at my last count) three separate press releases filled with misdirection and half-truths. Do check out ’s devastating indictment of Intel’s PR. Intel has not come clean about either the seriousness or long-term consequences of in particular, in contravention of industry norms. Tom Warren of The Verge Spectre Rather than holding itself accountable, Intel has been vague about whether we can even expect future hardware sufficiently re-engineered to address Spectre. Linus Torvalds, the creator of Linux who is arguably in charge of working around Intel’s mistakes within software, on the Linux kernel mailing list: was emotive I think somebody inside of Intel needs to really take a long hard lookat their CPU’s, and actually admit that they have issues instead ofwriting PR blurbs that say that everything works as designed. .. and that really means that all these mitigation patches should bewritten with “not all CPU’s are crap” in mind. Or is Intel basically saying “we are committed to selling you shitforever and ever, and never fixing anything”? Intel, in other words, has publicly articulated no specific plans to improve the security of its future products. Through its lack of transparency, accountability, or commitment to fix future products, Intel is behaving very much like a company unaccustomed to dealing with security vulnerabilities in its products. Even if Intel reformed overnight, change would come slowly. And unlike software companies, Intel and its competitors will never be able to properly fix pervasive problems in computers already manufactured — the silicon of a microchip cannot be magically rearranged from afar. Some bugs, like Meltdown, will require awkward software workarounds with unwanted side-effects. Others, like Spectre, will have no immediate or comprehensive solution, despite Intel’s assertions to the contrary. Insofar as hardware engineering mistakes can be remedied through firmware updates, those updates must be delivered to end-users through OEM cooperation. If you have a Dell with a vulnerable Intel component, your update will come from Dell. Mac users will receive updates from Apple, and so on. As Google learned from servicing Android, persuading cut-rate hardware partners to deliver timely updates to critical components is a fool’s errand. Consumers who purchased off-brand PCs from manufacturers no longer in business may remain nakedly vulnerable with no solution other than a new computer. While I do believe Intel, AMD, ARM, and other hardware powerhouses will get better at responding to problems as they emerge, I’m not of the opinion we should consider complex CPUs “secure” in the near future — certainly not ones from Intel. Most are developed in secret, tested behind closed doors, and not transparently reviewed by outside, independent experts. Where there is one bug visible, many more lurk in the black boxes of silicon that power our devices. What has changed is that now, hackers know where to look. This is only the beginning.

Spectre and Meltdown are just the beginning

How Spectre and Meltdown Could Impact Mobile Device Security At , we’ve been discussing the newly disclosed Meltdown and Spectre flaws and their impact on . Our CTO, Richard Taylor, wrote two blog posts giving a nice overview of the exploits and their likely impact on mobile device security. provides a clear explanation of the attacks and goes a little deeper than most. Part 2, focused on Android exploits, is included below to help get the word out. CriticalBlue device security Part 1 In of this blog I provided an overview of the Meltdown and Spectre and in this blog I look at the potential impact for mobile security. part 1 In all the furor this week it seems that Intel have bore the brunt of the outrage over the issue. Perhaps they should, I think they deserve it. They have not handled it from the PR perspective and the focus has been on Meltdown which almost exclusively impacts Intel. were instrumental in discovering the issues in the first place and have communicated in a timely and clear manner. However, when the dust settles on all this in a few weeks I rather suspect that Google and Android (which almost exclusively run on ARM cores) will be the ones feeling the ongoing pain of Spectre. well Google ARM The first variant of Spectre, Bounds Check Bypass ( ), essentially allows code to be written that has measurable side effects even if it is protected by a specific condition check that shouldn’t let it be executed. This is because this code may be executed speculatively and leave traces of that execution in the cache state. This bug is of particular concern for web browsers where it has been that Javascript can be constructed that triggers the bug and allows reading of any data within the process of the web browser itself. This may include all sorts of secret information that shouldn’t be accessible within the sandbox environment of browser Javascript. Fixes for browsers are already released or are on their way. Fortunately we have been here with browser updates, and since Android 5.0 Google are able to push updates to the browser automatically through the Play store via the normal app update mechanism. Thus the vast majority of devices will receive browser updates quickly and without interaction on the part of users. However, this still leave up to 20% of the installed base stranded on older versions that might not get an update at all for this serious bug. CVE-2017–5753 shown before may Of particular concern though is the second variant of the Spectre bug, Branch Target Injection ( ). You will recall that this is one that uses the Branch Target Buffer (BTB) poisoning to force a particular indirect branch to jump to an attacker controlled speculation gadget that is designed to leak some secret information into the cache state that can be read by the attacker later. This attacker requires to knowledge of the code, and the address that it is placed at, in order to generate the correct BTB poisoning and to know the locations of suitable speculation gadgets that are already in the code of the victim process.This particular issue has the opportunity to have a lasting impact on Android for reasons which I don’t think have been discussed sufficiently as yet: CVE-2017–5715 : This bug is present in a wide range of generations of ARM cores accordingly to their . The attack results in a large number of cycles of speculation since it is associated with branch prediction that occurs early in the pipeline. Thus there is ample opportunity for code sequences that can leave their footprint in the cache. Widespread ARM Vulnerability security update : Google are getting at this, but historically the Android ecosystem has been poor at getting patches pushed out to all their users. Google Android devices already have . There is the complexity of various OEMs and unsupported devices, users unwilling to press the system update button and devices with insufficient disk space to download the update. I think the bottom line is that there will be a very large number of Android devices out there that will not get patched to fix Spectre, ever. Some unpatched devices may be out there for a couple of . Apple have similar issues with Spectre but in their tightly controlled ecosystem they are much more successful at getting users to upgrade. Pushing System Updates better patches years : When a user downloads an app they are running native code that may be malicious and may be attempting to exploit Spectre to steal data from other apps on the device. Since native code is supported, very exact code sequences can be run. Google are doing their at looking for malicious apps via static analysis, but the code sequences to exploit Spectre can all be generated on the fly and triggered by some later event. It’s just really hard to catch this kind of thing as the various that make it into the Play store testifies. Remember that exploiting Spectre doesn’t need any weird app permissions, it just needs to be able to run code just like any app can. So if a user downloads an app that appears to work normally it may be doing something more sinister in the background. This has been a continual issue in the Android app ecosystem but Spectre seems to further ratchet this concern. We are still dealing with using Dirty COW on unpatched devices. Apps best banking trojans exploits : As I said earlier, in order to exploit the BTB poisoning variant of Spectre it is necessary to know the addresses of code that is running in a different process. Unfortunately all apps launched on an Android device share vast amounts of library code shared at the same address. This is all great from a memory saving and efficiency perspective but has never been good for security. For Spectre it seems somewhat disastrous. If you download a malicious app then it can immediately know the exact code content and addresses of system libraries of any app you want to attack. It seems likely there are various sites in those libraries that hold confidential data, such as key presses or characters to render for example, in register state just prior to an indirect branch or call. Thus an attacking app can synthesize a suitable BTB poison specially concocted for that branch that points to a suitable speculation gadget. The attacker app has got a lot of common system library and framework to choose that speculation gadget from. Moreover the BTB poisoning is easier as the attacker can use the actual indirect branch they want to target and make it branch to the speculation gadget of choice. When training (and thus the gadget is not speculative) this will probably crash but that is easily dealt with using sacrificial threads. This is much easier than having to guess how the BTB addressing works and line up something that will alias at the same address in the attacker’s process. The Zygote ( Again ) So where does this leave the security of sensitive Android apps that are running on unpatched devices? Exploiting Spectre is extremely difficult but now the approach is disclosed I have no doubt many will be trying. Will you trust your banking, payment, bitcoin app or indeed any dialog where you need to type in a password? All these questions will likely play out over the next few weeks, but it is clear that apps do need to start developing some better countermeasures against hostile environments in the near future. We have sophisticated root detection and defence in many apps already. Perhaps we need to be thinking about Spectre countermeasures too very soon. Thanks for reading! For more information on mobile API security, check out . www.approov.io I’d really appreciate it if you recommend this post (by clicking the 👏 button) so other people can find it.

The Spectre of the Zygote

dropped a on the security community last week detailing CPU bugs affecting , , and architectures going back as far as Pentium Pros. Yup, the chip with a mountain of cache and immortalized by Weird Al. Google’s Project Zero bombshell Intel AMD ARM There are actually a few variants of the bugs, collectively named and , detailed in the . Interestingly, the last line of the bug summary states: Meltdown Spectre official bug report All PoCs are written against specific processors and will likely require at least some adjustments before they can run in other environments, e.g. because of hardcoded timing tresholds[sic]. Indeed, hardcoding values is never a good idea as it often leads to inflexible code. This post explores how we might learn these thresholds with the help of deep learning. But first, let’s review how Spectre works. Spectre — or how to take advantage of CPU optimizations If you’re looking for the full explanation of this clever exploit, you can find the paper . In summary, Spectre takes advantage of two very popular CPU optimizations: and . When a CPU executes a bit of code that includes a branch attached to a memory value, since retrieving this value from RAM may take some time, the CPU may elect to execute past the branch. In higher level programming languages, branches are usually the result of conditional statements such as . When the value in RAM finally arrives, the CPU throws away the executed code if it happened to be wrong in its prediction. here branch prediction speculative execution if … then … This speculative execution has the side effect of copying RAM the CPU reads into cache and if this memory belongs to another process or, worse, the kernel, it will be cached before modern security systems realize the memory access is forbidden. Thus, malicious code can trick the CPU into caching privileged memory and then read out the cached value via a . This sort of attack exploits timing differences in how long a CPU takes to fetch values from RAM (slow) vs on-die CPU cache (fast). As the bug summary mentions, every CPU will exhibit different timing behavior. This is where deep learning comes in. side channel timing attack Deep Learning CPU Cache Timings To read the byte value of a privileged memory address, our attempts to read every possible 8 bit value at a given memory address — all 256 of them. We can’t directly read the value because the kernel won’t let us, but we can observe how long each read took. If a read is quick, chances are we hit the right value. Unfortunately, this isn’t always true as some values are always a bit faster to read (for example, 0 and 1) so assuming the fastest can lead to misread values. Let’s see how we can use a deep learning model to improve read accuracy. proof of concept code The full proof of concept code can be found and I’ll include only the most relevant bits from here on. To get started, we’ll build our training data using a string of possible byte values and their observed cache timings: here data_x = np.zeros([n_samples, 256])data_y = np.zeros([n_samples, len(unique_chars)])for i in range(n_iterations):for j, val in enumerate(secret_chars):data_x[i * n_chars + j, :] = deep_spectre.train(j)data_y[i * n_chars + j, char_to_idx_map[val]] = 1 contains our training data and contains our target data. Each row of represents an observation of all 256 cache read timings for a single byte value. Each row of contains the byte value, . Neural networks are typically sensitive to large values so we’ll normalize (0 mean, unit variance) the timings using handy scaler. We’ll also split the training and target data into training and validation sets. The validation set contains data the model never sees while training and provides a reasonable metric of how well the model will perform in the wild: data_x data_y data_x data_y one hot encoded Scikit Learn’s scaler = StandardScaler()data_x = scaler.fit_transform(data_x)x_train, x_test, y_train, y_test = train_test_split(data_x, data_y) Now for the exciting part — let’s build a simple deep model. We’ll use the to wrap and build a four layer densely connected neural network. If you’re curious about neural architecture, I’d encourage you to check out the Keras has to offer. Keras API TensorFlow other layer types model = Sequential()model.add(Dense(200, input_shape = (256,), activation = ‘relu’))model.add(Dense(150, activation = ‘relu’))model.add(Dense(100, activation = ‘relu’))model.add(Dense(len(unique_chars), activation = ‘softmax’)) model.compile(loss = ‘categorical_crossentropy’,optimizer = ‘adam’,metrics = [‘accuracy’]) model.fit(x_train, y_train,batch_size = 32,epochs = 10,validation_data = (x_test, y_test)) The call to will start the training process. If all goes well, our model should achieve above 90% accuracy. Running this on my machine yields: model.fit() Train on 48000 samples, validate on 16000 samplesEpoch 1/1048000/48000 [ ] — 4s 73us/step — loss: 0.4543 — acc: 0.9007 — val_loss: 0.3505 — val_acc: 0.9204Epoch 3/1048000/48000 [ ] — 3s 73us/step — loss: 0.2516 — acc: 0.9441 — val_loss: 0.2948 — val_acc: 0.9293Epoch 5/1048000/48000 [ ] — 4s 73us/step — loss: 0.2320 — acc: 0.9460 — val_loss: 0.2765 — val_acc: 0.9360Epoch 7/1048000/48000 [ ] — 4s 74us/step — loss: 0.2324 — acc: 0.9468 — val_loss: 0.2502 — val_acc: 0.9403Epoch 9/1048000/48000 [ ] — 3s 72us/step — loss: 0.2277 — acc: 0.9467 — val_loss: 0.2663 — val_acc: 0.9392 ] — 4s 83us/step — loss: 2.9168 — acc: 0.3363 — val_loss: 0.7985 — val_acc: 0.8276Epoch 2/1048000/48000 [ ] — 4s 75us/step — loss: 0.2802 — acc: 0.9367 — val_loss: 0.2825 — val_acc: 0.9335Epoch 4/1048000/48000 [ ] — 4s 73us/step — loss: 0.2368 — acc: 0.9451 — val_loss: 0.2640 — val_acc: 0.9361Epoch 6/1048000/48000 [ ] — 3s 73us/step — loss: 0.2405 — acc: 0.9458 — val_loss: 0.2588 — val_acc: 0.9376Epoch 8/1048000/48000 [ ] — 4s 73us/step — loss: 0.2269 — acc: 0.9474 — val_loss: 0.2452 — val_acc: 0.9408Epoch 10/1048000/48000 [ Now that we have a trained model, we can use it to predict unknown byte values given only cache timings. For example, let’s read a 40 byte secret string: secret_len = 40x_message = np.zeros([secret_len, 256])for i in range(secret_len):x_message[i, :] = deep_spectre.read(i) After passing to , we simply take the output neuron with the highest probability via and map it back to a byte value: x_message model.predict() np.argmax() y_pred = model.predict(scaler.transform(x_message))pred_chars = np.argmax(y_pred, axis=1)message = ‘’.join(list(map(lambda x: chr(idx_to_char_map[x]), pred_chars)))print(“The secret message is:”, message) If everything went according to plan, we should see: The secret message is: The Magic Words are Squeamish Ossifrage. Packaging these deep learning frameworks with an exploit would make for a prohibitively large payload. However, it may be possible to employ to reduce the size of the model. It’s certainly not difficult to imagine a new breed of neural exploits armed with deep learning models to overcome idiosyncrasies found across CPU architectures and software versions. TensorFlow Lite Of course, this remains purely speculative ;)

Exploiting Spectre with Deep learning

Over the last couple of days, two major vulnerabilities — Spectre and Meltdown — have surfaced. These vulnerabilities, which affect nearly all intel chips from the past decade, are two of the most — if not the most — dangerous vulnerabilities the IT world has ever seen. Every time a big new vulnerability comes out, however, the public is given rudimentary explanations that never really get to the point of the issue and, in turn, non-IT people never really know whats going on. In this article, I’m going to try to explain these two extremely dangerous and complex attacks as if you were a super hero-loving 5 year old. First, the kernel: These attacks affect the kernel of an operating system. Before my super-hero analogy, allow me to explain the kernel at a slightly higher level: The Kernel is the core of an operating system and has complete control over everything (processor, memory, chips, etc.) on the system. Whenever a program needs to do anything (i.e. write to files, open network connections, etc.), it hands control of user-space processing to the kernel temporarily. Now, for the analogy: Whenever Batman and the rest of the Justice League are out fighting mega-criminals, Alfred (the kernel) is handed control of the Batcave (the processor) so that he can provide important information and help the group win. When the team defeats the bad guys, Batman relieves Alfred of his control and takes the Batcave back. Now, let me explain Spectre Google’s release of this attack came in the form of a detailed technical paper which described Spectre as follows: Spectre attacks induce a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim’s confidential information via a side channel to the adversary. Now for the analogy: During their time off between battles, the Justice League likes to play hide and seek in Batman’s mansion. Normally, everybody hides and the seeker has to go around and search for all the other people. However, today it’s Superman’s turn to seek and he just doesn’t want to play! Instead of honestly going around and searching for the rest of the team, Superman decides to cheat and use his x-ray vision. Now, Superman can see exactly where everybody is! In addition, he now knows where Bruce hides all his valuables — including his bespoke Superman action figure! OK, now for Meltdown: First, let’s look at Google’s description: First, an attacker makes the CPU execute a transient instruction sequence which uses an inaccessible secret value stored somewhere in physical memory. The transient instruction sequence acts as the transmitter of a covert channel, ultimately leaking the secret value to the attacker. Now, let’s take a look at the analogy Batman is trying to recruit the flash to the justice league. As he and the flash are walking down the street, Batman whispers the location of the bat cave into the flash’s ear. Unfortunately for them, the Joker has installed super advanced listening devices all over the city and now knows exactly where the Batcave is. Wowza… that’s… really bad! How can I protect myself? Unfortunately, there’s really not much you can do as a normal user to protect yourself. These attacks constitute a whole new genre of vulnerability in modern computers and the only solution is waiting for an operating system patch to come out. Luckily, Microsoft, Apple, and the open source developers working on Linux have already pushed out patches that should prevent this attack and researchers all around the world are working to replicate, mitigate, and prevent attacks such as these from happening again.

Explain Spectre and Meltdown Like I’m 5

TL;DR: a PoC demonstrating Spectre , the nasty CPU bug, running on Kubernetes. If you haven’t been living under a rock, you have heard about , two really nasty hardware bugs, affecting many if not all modern (desktop and server) CPUs. Meltdown and Spectre So, when reading up on those two fellas I was asking myself: how do they impact a cluster and/or apps running on it? Given there’s an , what would be easier to put it into a like so: Kubernetes example C source code available for Spectre container And then run it in Kubernetes, for example, using: $ kubectl run spectre \--image=quay.io/mhausenblas/spectre:0.1 \--restart=Never Turns out that works. Checking the logs with: $ kubectl logs spectre That’s it! Well, 2018 certainly started, erm, very interesting. We’ll have a lot of work in front of us—I’ve seen first being worked on—and for now the best we can do is not to pull random images from untrusted registries and run in our clusters, but I suppose you knew this already and (hopefully) don’t do it anyway. issues Some thoughts an a disclaimer: this PoC is a low-hanging fruit, it’s using a way too big image (heck, 500MB!), it doesn’t prove any general attack, just that the known exploit can be packaged as a container and run in a Kubernetes cluster. Also, I’m not speaking on behalf of my employer or in any official , I was just interested in how hard is it to carry out this exercise in a containerized environment. capacity

Spectre-on-Kubernetes, a proof of concept

Example code demonstrating the Meltdown attack ( ) http://meltdownattack.com/ A coordinated disclosure overnight brought forth details of two large vulnerabilities affecting nearly all computer users worldwide. This comes after days of mounting speculation online following benchmarks of an unexplained bug fix reportedly causing performance losses of anywhere from 5 to 30% depending on the task at hand. Discovered independently by separate teams of researchers from Google’s Project Zero, German firm Cyberus Technology and several universities worldwide, these vulnerabilities been dubbed and Spectre, in part owing to their severity and pervasiveness. security Meltdown If you own a computer, mobile phone or any other device made in the last 20 years, this is likely to affect you. The good news is that updates to help mitigate the affects of these vulnerabilities are rolling out now and will continue to do so over the coming weeks. The bad news is that to a certain extent, these attacks exploit the fundamental architecture of modern processors and so are likely to require entirely new hardware to completely fix it. Right now, the best thing you can do to help protect yourself is to install any updates for your operating system, web browsers and other critical pieces of software as soon as they become available. We should all be updating our software regularly anyway, but this is not always the case as we saw with the WannaCry ransomware attacks in 2017, an incident that could have been easily prevented by a Windows bug fix that had been available for nearly 2 months. Expect a similar story to play out again in the coming months as malicious actors take advantage of those who haven’t updated their systems.  I’ll include links in the footer to relevant updates and will endeavour to update this list as more information becomes available. So having got that out of the way, what are these attacks exactly and how do they work? At their core, Meltdown and Spectre allow an attacker to access computer memory that they ordinarily would not be able to. Additionally, the Meltdown vulnerability which specifically affects nearly all Intel processors, allows arbitrary access to ‘protected’ memory, an outcome that fundamentally breaks the security systems put in place in modern operating systems. Using this unrestricted memory access, an attacker can easily read passwords and other sensitive data that was previously assumed safe from prying eyes, even though it is kept “secure” by current best practices. Proof of concept using Meltdown to reveal passwords To do this, both Meltdown and Spectre take advantage of speculative execution, a feature introduced in the 90s and used by processors to speed up execution of programs. To try and explain how this works, imagine you and a friend are walking through the bush and you reach a fork in the trail. You’re not sure whether you need to go left or right, so your friend pulls out a map and tries to figure out where you are and which way you should go. Now, knowing your friend, this could take a while to get an answer, and the track you’ve been following requires you to clear branches out of the way as you go. Without speculative execution, you’d stay with your friend until you knew the correct way to go, but in your mind that’s just wasting time. Instead, as an impatient speculative executor, you decide that there’s a good chance the correct path is the one on the right and so while your friend is still busy at the fork, you’re marching ahead to clear the way. This could turn out to be the wrong path, in which case you’d be able to quickly run back along the cleared track to the fork and take the other path with your friend, clearing it as you went much like if you’d just waited. Or it could be the correct path, in which case you’ve saved time by clearing the track in advance and your friend quickly catches up to you. A similar story is playing out in your computer with the processor or CPU. The processor reaches a fork that depends on some value. Accessing the RAM where this value is stored takes a (relatively) long time, so while that’s happening the processor takes a chance at one of the outcomes and carries on it’s way. If it was the right choice, life is good and your computer is faster as a result, but if not, the incorrect work is quickly thrown away and the correct path is taken. This sort of out of order execution is great in theory, as it allows the processor to be doing something at all times rather than sitting idle, but there are some subtle nuances with it’s implementation that are causing the issues we are now seeing. Within your computer there are several different types of memory, each with a different order of magnitude of speed. As a general rule, the faster the memory is, the less you’ll have of it. One of the fastest types of memory in your computer is it’s cache, and it’s small — the fastest cache often only stores 32kb of data (a mere fraction of a photo from your phone for example). Now, your computer likes to be able to access the information it needs quickly and so it tries to keep useful data in this fast cache for quick access. Unfortunately what constitutes useful data is often hard to predict in advance, so most processors make the assumption that if a piece of data was recently used then it is more likely to be used again in the near future and will store it in the cache. Just like speculative execution before, this is a good thing for making your computer faster and in theory shouldn’t cause any trouble. Now we get to combine our two favourite CPU optimisations. As a result of speculative execution, the processor reaches a fork and continues down one path in anticipation. Whilst doing so, it’s accessing more values from memory and some of these will end up stored in the much faster cache in order to speed up subsequent use. It may turn out that this was the wrong path, and the processor goes back and follows the correct one, discarding the incorrect work it did along the way. However, the values loaded into the cache are kept there because they might still be useful in the correct path, and because nothing else has yet been loaded that could replace it. This is where the fun begins. What happens next is tricky for me to explain in detail, so I’ll do my best to convey the general idea in a somewhat accessible manner that’s hopefully still true to the underlying principles. An attacker can construct a program that will try to access protected memory in a branch (our fork in the trail from earlier) that the processor speculatively executes. During ordinary, non speculative execution, the protective measures in place to stop such unauthorised memory access would prevent the data from being accessed and loaded into the cache. However, during speculative execution these measures are only applied once the branch has been verified as the correct one to follow. If the attacker ensures that the branch containing this protected memory access is not the correct branch, then these permissions are never checked, but the requested value is still loaded as mentioned earlier. While direct access to the newly loaded data in the cache is not possible, it is possible for a cleverly constructed program to load different items into memory in a perfectly legal way based off the protected value. For example, during speculative execution I might load memory “box” 10 if the protected value is a 0, or load memory “box” 11 if it’s a 1 (for simplicity let’s say it can only be these two values for now). Once the processor has determined that it shouldn’t follow the branch and has continued normal execution, the attacker can measure the time taken to load memory “box” 10 and 11. Since only one of the boxes should have been loaded previously, one box should load significantly faster as it’s already in the cache where as the other is in a slower form of memory. Congratulations, you’ve managed to leak protected data despite the various measures typically employed in your computer to stop you from doing so. Rinse and repeat to potentially expose all the data in memory on your computer. These sort of attacks are known as side-channel attacks, and rely upon physical phenomena to glean extra information out of a system. In this case, Meltdown and Spectre are timing based side-channel attacks, using the fundamental properties of different hierarchies of memory in a modern computer system. As mentioned earlier, this makes them especially hard to fix since they’re a property of a physical device rather than a logical error in a sequence of instructions for a piece of software. The Intel specific Meltdown bug relating to highly privileged memory access is more easily fixed in software, and the fixes for this are currently being made available. You might see the names KPTI or KAISER thrown around in update descriptions. These relate to Meltdown so please install them as soon as possible. Mitigations for Spectre are a more troubling situation. Not only does it potentially affect your computer, but also your phone and any other modern computing device regardless of the processor inside. Minimising it’s impact is going to take time and effort from software companies around the world. At high risk are web browsers like Chrome, Firefox and Safari, as code executed by a webpage can potentially trigger the vulnerability. Browser updates with various mitigations are due out in the next few weeks, but there are ways to enable some of these now. Details for these are in the footer and I will do my best to update them as required. Long story short, there’s a couple of serious design flaws in almost all modern processors that allow arbitrary memory access, potentially revealing sensitive information like passwords and encryption keys to an attacker. It’s going to take a while to fix everything properly, so in the interim make sure you install any updates as soon as they become available. These attacks were first disclosed to relevant organisations like Intel as far back as 6 months ago. Given that multiple independent groups were part of the disclosure, there’s a chance that these vulnerabilities were also discovered by other groups and potentially weaponised to steal data already. As such, the usual security advice applies — avoid dodgy looking downloads and websites, keep an eye out for suspicious activity emails like password resets and ensure you’re using strong, unique passwords for each website. I’ve found password managers to be super helpful with this, and I’ll link my current choice down below. I hope that this explainer has been useful in understanding what’s going on with these recent vulnerabilities. Whilst putting this together, I’ve been keeping an eye on the mainstream news here in Australia and this has barely registered. Meanwhile, the pace at which people around the world are playing with these exploits and sharing their findings is staggering and it won’t be long before some real damage takes place. I imagine we’ll be hearing a lot more about Meltdown and Spectre in the coming days and weeks, so update your devices, get those around you to do the same and then grab some popcorn. Further reading https://meltdownattack.com I highly recommend the use of a password manager to keep track of strong, unique passwords for all your logins. My current password manager of choice is RememBear ( ) https://www.remembear.com Updates you should apply: Windows: Microsoft is in the process of rolling out an update via Windows Update and should be available around January 9 https://www.theverge.com/2018/1/3/16846784/microsoft-processor-bug-windows-10-fix MacOS: Apple issued a partial fix in MacOS 10.13.2 (check using the Apple icon > About This Mac). Further fixes are apparently coming with 10.13.3 in the near future. Chrome: Chrome 64, due on January 23, will contain mitigations. In the interim, the “Site Isolation” setting can be enabled by following the instructions at https://support.google.com/faqs/answer/7622138#chrome Other pieces of software should be updated as required. 2018 is the year I try and do something a bit different. Follow along with my other creative endeavours on or Instagram YouTube

Meltdown and Spectre: what are they and what should I do?

Photo by on Carlos Muza Unsplash The end of 2017 has seen some pretty ridiculous headlines about the tech industry. 2018 will be the year the cool tech guy in the hoodie is finally revealed to be the tech guy who’s “hacking” your attention to get more money from advertisers. It’s going to be the year that “Move Fast and Break Things” turns into “Move Slow and Check For Bugs”. not so cool This week saw the release of the “bug” called . Spectre means that speculative execution is a major vector for attacks on all machines. Speculative execution is a technique that’s the basis for a lot of the speed increases in modern computing. Here’s the rub, speculative execution is done at the level. This means that even if you patch the kernel of the operating system you’re not truly fixing it until they release new processors. It’s not even a bug, it’s a logical error in the design of Spectre hardware every processor made after 1995. Now let’s talk about , your second favorite thing your relatives ask about over Thanksgiving dinner. A few days ago Kodak released a cryptocurrency called . It’s supposed to help right’s holders get paid for their photos.Why do they need the blockchain for this? To hash the names of owners of pictures? metadata contains copyright information. Every image file has EXIF data in it already. Finally, why is it not called KodaCoin? Bitcoin KodakCoin EXIF This will be the year people remember what Bitcoin was designed to do. It’s original incarnation was a way to wrest control of currency away from governments and banks. Bitcoin isn’t an investment vehicle, it’s supposed to be a currency. There’s a positive aspect of the Bitcoin bubble deflating. We can start looking at the interesting that underlies Bitcoin. Not just the amount of money . technology someone accidentally made by making a joke currency I hope the combination of Bitcoin hype, Snap’s IPO failing, and realizing all Computer Scientists have been wrong for 20 years will make for a saner 2018.

2018 Will be the Year of Sane Technology

How Meltdown and Spectre are Breaching Device Security At , we’ve been discussing the newly disclosed Meltdown and Spectre flaws and their impact on . Our CTO, Richard Taylor, wrote a giving a nice overview of the exploits. It’s a clear explanation and goes a little deeper than most, so I have included his thoughts below to help get the word out. CriticalBlue device security blog post There is much to discuss in the wake of the security news flow last week. It was dominated by the CPU bug announcements — 2018 has certainly got off to an interesting start. In part one of this two part blog I will look at these bugs from a high level. In part two I shine the spotlight on the implications for mobile security, and for Android in particular. Meltdown and Spectre Although patches for these bugs have been in the works for some time, the announcements have been rushed out and it has showed at times. However and amongst others have provided some excellent coverage which I won’t repeat again here. The Register Ars Technica Cache side channel attacks are but until now many of those attacks have been somewhat contrived. For the attack to work, there needs to be a strong signal coming from the victim application you are trying to eavesdrop upon and locating this has been the biggest challenge for the attacker. In this context a strong signal means a cache line access pattern that itself reveals some secret data. In other words the data has to influence the memory access pattern in a particularly convenient way. Some key piece of data you are trying to steal needs to be used to calculate addresses that conveniently span lots of cache lines to give you some good cache side channel information to spy on later. Furthermore you need that cache layout to remain intact long enough that your eavesdropping code can observe it. Often, the cache layout information is quickly degraded by other operations being performed by the code under attack. These requirements don’t occur very frequently in reality, so although there are some nice demos of side channel communication the opportunities of finding a good signal generator in the code you want to attack is actually rather slim. not new Meltdown and Spectre change the game fundamentally. You get to make your own signal generating code that you can then eavesdrop upon yourself. Very convenient. This is much more generic and much more powerful. The key insight here is the use of speculative execution to do this for you. To maintain decent performance, CPUs execute speculatively quite a lot of the time. In particular they predict which way branches are likely to take and as it turns out they effectively predict that, sure, you are definitely allowed to access that memory location you just read from. First let us deal with Meltdown, which effectively only impacts Intel CPUs. Formally this is Rogue Data Cache Load ( ), a rather clever abuse of the out of order speculative nature of CPUs. The first thing you do is you load from a memory location that are not meant to have permission to read. When you do this your code is going to get an exception and it is going to stop, and certainly not tell you directly what was held in that memory location. But, as it turns out, it doesn’t do that right away because it deals with the exception as a separate sub-operation to the load itself. So if you cleverly construct your code you can actually take the data load and transform it into an address and then load from that location. Now when the exception finally catches up with you all the register state you got from the original load gets rolled back. Washed away as if it never happened. However, the fact that you read from that data dependent address is still left in the cache state. It isn’t washed away. This vestige remains and with careful measurement of the cache state from another thread in your code you can infer what the data was. This is very bad news. Now you can effectively read any memory you want to, albeit a little statistically and very indirectly. The really terrible news is that by default Linux and Windows make all of the machine’s memory accessible in the process address space. So all the secret data, passwords and other useful nuggets are potentially accessible to your attack code. If you can get your code running on the target machine then you can read anything you want in theory. A pretty devastating oversight in the security isolation of CPUs. It is truly remarkable that this hasn’t been obvious before now. Speculative execution has been around for many years. It is one of those insights which results in a collective sigh of “of course, why did nobody think of that before” once you realise its implication. Patches to fix Meltdown have been in the works for a while and are ready to roll out soon. Basically the fix is to make sure the only pages that are MMU mapped for a process are ones that it should be able to read anyway or are otherwise not very interesting. This is termed Kernel Page Table Isolation ( ) for Linux, and there is a similar fix for Windows arriving soon. This has a performance impact though. There were good reasons to make the rest of the kernel pages quickly accessible. Even though systems will see a drop in performance, we will be safe from Meltdown. So although much of the initial hysteria has been around the impact of Meltdown, especially in multi-tenant cloud environments such as AWS, it seems that the patch cycle should catch up soon and Meltdown will then likely drop out of the headlines. Although the main Meltdown bug does not impact ARM CPUs, they define a special whereby certain system register contents can be leaked to ordinary processes but overall this seems less serious than the Intel variety. A PoC on ARM hardware is already . CVE-2017–5754 KPTI variant 3a running I suspect that Spectre will be the bug that keeps on giving. It will certainly haunt us for years to come as been pointed out by the researchers who found this vulnerability. Its implications are deeper and are more difficult to mitigate. Unlike Meltdown, Spectre equally impacts ARM and AMD devices. This means that phones and tablets are in the frame too for Spectre related data leaks. There are two variants of Spectre. The first is termed Bounds Check Bypass ( ). Basically this requires a rather particular sequence of code including a range check of a conditional value. It uses the branch prediction to execute a block of code that shouldn’t be executed. The idea is to train the branch predictor to execute some conditional code and then pass in a value that means it shouldn’t. However the conditional check needs to be carefully constructed so that it can’t be evaluated straight away. Thus, rather than wait and waste time, the CPU will go ahead and execute the conditional code just like it did last time. What’s the harm, right? There is nothing better for it to do. The conditional code is constructed to load data from an arbitrary, attacker controlled, memory location and then use that data as an address to load from memory again. There are obvious similarities with Meltdown here. That second load leaves its impact in the cache layout even after the processor catches up with itself and realises it should have never executed that code path after all. So basically you can read any piece of memory that the process can read. You also need a relatively contrived code sequence to do it, one that is less likely to occur naturally so you really need to be able to generate that code yourself. The bug allows you to effectively load from memory that the process can load from anyway. What’s the big deal you might ask. Well the big deal is JIT and user generated code that is running in the context of a process. Memory bound checks will typically ensure that such code cannot just read arbitrary memory, only the parts it is allowed to in its little sandbox. This Spectre variant allows escape from the sandbox. The disclosure shows how Javascript can be constructed that is then JITted to generate the exact sequence to exploit this bug. Now Javascript running in a web page can potentially access all of the browser process memory. This might include all sorts of passwords, credentials, cookies and other useful confidential tidbits that should not be accessible to whatever rogue Javascript running advert wants to steal your data. The fact that many browsers run each tab in a separate process doesn’t seem quite like the act of extreme tin-foil hatted-ness that I thought it once was. Suddenly it seems awfully prescient. The other thing I discovered yesterday for the first time is that even the Linux kernel has a JIT! Apparently there is a thing called that can be exploited to leak arbitrary kernel data. Needless to say that fixes are in the pipeline for all these things, but they are more complex and require different code sequences to be generated with special fence instructions to ensure that bad speculations cannot leak confidential data in this way. The wider, longer term implication of all this is you can’t trust user code that you allow to run in the context of your process unless you really think about it. Even if you sandbox that code so you limit what it can access that won’t necessarily be sufficient. Suddenly we have to realise programs live in a strange quantum like world, and can actually take code paths that they never should. The veil of abstraction over speculation execution has been breached. CVE-2017–5753 eBPF Now we come to the second variant of Spectre, Branch Target Injection ( ). This one seems the most bizarre of them all. Again this is related to branch prediction, but this time to indirect branches. Indirect branches happen reasonably frequently, especially in object oriented languages that allow polymorphic method overrides. So it is quite important to speed them up, otherwise they would be rather slow. This is because the CPU can’t even start filling its pipeline until it knows what instruction to go to next, and modern CPUs have rather long pipelines to be filled. As it turns out, where a particular indirect branch went last time is a rather excellent predictor of where it will go next time. So again, in the absence of anything better to do, a typical CPU will do exactly that and execute speculatively to the last target. To support this there is a table in the CPU called the Branch Target Buffer (BTB) that records a mapping from an instruction address to where that instruction will likely go to if it is an indirect branch. So this gets updated when the determination is made to predict for next time. Of course this table can’t be infinitely big and there are some collisions between the entries but most frequently executed instructions will be retained. It acts just like a cache of recent indirect branches and in some architectures is called a Branch Target Address Cache (BTAC). The BTB content is retained if your code stops executing and then passes to the kernel and then perhaps on to some other process running on the same core. It makes sense to keep the entries because some of the valid ones might still be there by the time it is your code’s turn to execute again. There is no point in throwing away potentially useful information that speeds up execution and what is the harm? If the target address was wrong then the CPU didn’t have anything better to do anyway, and the incorrect execution can just be rolled back as if it never happened and then the correct destination can be branched to. Well I’m sure you can see where this is going. As we know already, speculative execution is not without side effects as it turns out and these can be exploited. CVE-2017–5715 The really clever trick with Spectre Branch Target Injection is that an attacker can get to choose what code is speculatively executed. If the attacker knows the address of a particular indirect branch then they can train the BTB to point to where they want it to. That needs to be code that is already in the process being attacked, but let’s presume that the attacker knows what and where that code is. The code doesn’t need to execute cleanly, it just needs to execute long enough that it is going to leak something useful into the cache state to examine later. This code is speculative, and it will be the wrong prediction anyway, so will be rolled back. So basically if the attacker wants to know the value of a particular register at an indirect branch call site then they need to find some code that uses that register in an address calculation and memory load that will leave a distinctive enough trace in the cache state. There is an extremely strong parallel here with ROP gadgets. These are short sequences of existing code that an attacker can cobble together to do something useful if they can cause a buffer overflow in a process that allows them to control a target address, but can’t inject new code. Buffer overflows and ROP gadget chains are the scourge of application security. What we have in the Spectre case are speculation gadgets. We can choose just the right existing code sequence in the existing code that will give us the leakage signature that we want. Unlike ROP gadgets though we don’t need an existing vulnerability like a buffer overflow to exploit them. We just need to have run earlier and have set our trap in the BTB to force another process’s code to incorrectly speculate and leave us some useful state in the cache that we can examine later. Of course in practice this is hard to setup and seems to be much easier to leak small blobs of information (such as individual bytes or words) rather than data blocks since our poisonous BTB training is soon undone and we have limited capacity for transmitting data through the cache state. It seems to me that the most obvious use for such an attack is for software key logging. Potentially every register that is live at an indirect branch site is susceptible to leakage. We just need to find one that, for instance, holds the value of the last key press on a system. This may of course be part of a password or confidential message. Not good. Note that in order to exploit this Spectre variant it is necessary to know the exact code layout of the process you are trying to attack. You need to know this so you can set your BTB trap correctly for the indirect branch that is being subverted. Since Address Space Layout Randomization ( ) is widely used nowadays, as a defence against ROP Gadget attacks, this is not necessarily straightforward. There are various techniques around to try and infer the code addresses but this does add another layer of complication in the already byzantine causal chain required to make this attack actually work. ASLR Fixes are also in the works for this flaw. In particular the approach relies on BTB training existing beyond the boundary of a context switch. Intel have a coming that will disable the retention of the entries across the boundary, effectively rendering this bug unexploitable. ARM have similar patches available that can disable or clear the BTB across context switch boundaries. At this stage it is unclear what the performance impact of this is going to be. There is definitely going to be some. The BTB content is traditionally retained for good performance reasons. Compiler patches are also coming in the form of the new “ ” feature. This allows an application to be recompiled so that it is no longer susceptible, or indeed the kernel can be recompiled with this feature on. This is particularly for cases where an application might be run in an unpatched environment. Retpolines seem rather ugly but fix the issue. They basically cause the compiler to replace indirect branches and calls with a more complicated and slower sequence that abuses the return instruction to do the same thing. This is much slower but not susceptible to Spectre as returns don’t use the BTB for prediction. It is unclear when and if similar Retpoline fixes will come for other compiled and JITted languages such as Java, C#, Python or Go.In part two I discuss what this all means for mobile security. These bugs are definitely not restricted to Intel devices only. microcode update retpoline Thanks for reading! For more information on mobile API security, check out . www.approov.io I’d really appreciate it if you recommend this post (by clicking the 👏 button) so other people can find it.

Stories, News & Mentions about SPECTRE

Spectre’s Stories on HackerNoon

Spectre's News & Mentions