In part1 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.
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 well from the PR perspective and the focus has been on Meltdown which almost exclusively impacts Intel. Google were instrumental in discovering the issues in the first place and ARM 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.
The first variant of Spectre, Bounds Check Bypass (CVE-2017–5753), 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 shown 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 before 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 may 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.
Of particular concern though is the second variant of the Spectre bug, Branch Target Injection (CVE-2017–5715). 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:
Widespread ARM Vulnerability: This bug is present in a wide range of generations of ARM cores accordingly to their security update. 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.
Pushing System Updates: Google are getting better at this, but historically the Android ecosystem has been poor at getting patches pushed out to all their users. Google Android devices already have patches. 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 years . Apple have similar issues with Spectre but in their tightly controlled ecosystem they are much more successful at getting users to upgrade.
Apps: 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 best 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 banking trojans 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 exploits using Dirty COW on unpatched devices.
The Zygote (Again): 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.
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.
