A trio of bugs caused by programming inconsistencies could have opened up Android 7, 8 and 9 to remote attackers wielding booby-trapped image files.
In Google’s own words:
[These bugs] could enable a remote attacker using a specially crafted PNG file to execute arbitrary code within the context of a privileged process.
If you want to track the bugs by number, they are handily sequential: CVE-2019-1986, CVE-2019-1987 and CVE-2019-1988.
The bugs were inherited from an open-source image handling programming toolkit called Skia that is bankrolled and managed by Google, and used as the graphics engine in many products, including Chrome, ChromeOS and Android.
(The bugs described in this article notwithstanding, Skia is worth looking at if you are after a free and liberally-licensed graphics library that runs well even on low-powered computer hardware.)
This crop of bugs involves uninitialised variables and imprecise error handling in the code responsible for processing PNG image files.
Feeding malformed PNG files into Skia’s image rendering code could cause it to access and use memory that it shouldn’t.
In theory, this sort of flaw means that attackers can almost certainly make Skia crash, and may even be able to trick it into failing in a way that they can control.
For example, if you can trick a program into consuming and trusting memory that it didn’t initialise itself, and you can find a way to manipulate the contents of that not-safe-to-use memory ahead of time…
…then you have a fighting chance of creating a remote code execution exploit, or RCE.
Typically, RCEs based on memory mismanagement involve persuading a program into downloading and using booby-trapped data – something that ought to be perfectly safe, if the error-checking in the program is correct – and then tricking the program into treating some of that data as code, executing it instead of merely processing it.
Safe by default?
Bugs that can be triggered by image files such as JPEGs and PNGs are particularly handy for attackers, because it’s not considered controversial for software such as your web browser to fetch and display images from remote websites by default.
We’re generally careful about opening files such as PDFs, Word documents and programs if we downloaded them from the internet or received them in email attachments, because we know they can contain risky add-in components such as macros, scripts and so on.
Indeed, PDFs, DOCs and EXEs can all be active carriers of malware, even if the files aren’t deliberately malformed and there are no bugs for them to exploit.
But images aren’t supposed to contain executable code, and even if they do, it’s not supposed to cause problems, so browsers and image viewers that fetch picture files from remote web servers generally just process and display them without so much as a by-your-leave.
That’s why potentially exploitable bugs in the software libraries that your operating system uses to display images are often greeted with great concern.
How bad is it?
The bad news in this case is that the bugs affect Android 7, 8 and 9, so just having a modern and supposedly safer flavour of Android won’t protect you.
The good news is that the bugs were patched in Google’s February 2019 update.
Of course, given the size and variability in the Android ecosystem, it’s anyone’s guess when, or even if, the relevant patches will filter down to your phone.
The other good news is that it doesn’t seem to be the Bad Guys who found these bugs first, because there’s no sign that they’ve been abused in the wild to mount attacks.
As a result, the RCE danger in this case is more theoretical than practical.
In fact, not all potential RCE vulnerabilities can be turned into working attacks, thanks to mitigations such as DEP and ASLR.
DEP is short for data execution prevention, and it’s a method by which the operating system will refuse to run as code anything that was originally presented as data.
ASLR is short for address space layout randomisation, and it’s the technique of loading system software at a different place in memory on every device, so that attackers can’t guess where to find the vital sytem functions or data they need to access to make their exploits work.
What to do?
If you’re an Android user on version 7 or later, make sure you’ve got your February 2019 updates.
If you haven’t, ask your handset vendor or carrier when you can expect them to arrive.
Keeping pressure on Android providers to move quickly when it comes to patches is one way you can help put an end to the inconsistency and confusion around updates that characterise the Android ecosystem.