Serious crypto vulnerability in Android

The whole mobile/android world was shocked when a new vulnerability was disclosed which, to sum it up, weakens the security of the built-in KeyStore. However, the Android fanboy in me, couldn’t help but notice that a lot of media fail to cover the story in a correct manner. Bear with me here, it will get a little bit technical.

“The vulnerability resides in the Android KeyStore, a highly sensitive region of the Google-made operating system dedicated to storing cryptographic keys and similar credentials, according to an advisory published this week by IBM security researchers. By exploiting the bug, attackers can execute malicious code that leaks keys used by banking and other sensitive apps, virtual private network services, and the PIN or finger patterns used to unlock handsets. The advisory said Google has patched the stack-based buffer overflow only in version 4.4, aka KitKat, of Android. In an update, IBM said the vulnerability affected only version 4.3, which runs on about 10.3 percent of handsets.”

Now, a stack-based overflow itself is not that hard to exploit. However, every self-respecting security team in a big software company knows and implements countermeasures against these exploits/overflows. Android for example uses as 2 major ones: data execution prevention and address space layout randomization (ASLR). Without the technical details, this makes it pretty hard for an attacker to execute its own malicious code. But assume for now, that an attacker has the possibility to do this. It’s still pretty difficult to actually exploit this. Whenever you inject code into the stack on the Android OS, the code is converted to an ASCII 7-bit representation. So what, you may ask. Well basically this reduces the set of instructions that can be executed. Because of this 7-bit representation, the most significant bit is changed to 0 and you can’t encode values less than b’0011000. This restricts us to code words of the form b’ 0xxxxxxx 0xxxxxxx 0xxxxxxx 0xxxxxxx. Now consider this chart which represents the instruction set for an ARMv7 CPU, frequently used in Android devices.

Instruction set ARMv7 CPU

Instruction set ARMv7 CPU

If you look at the chart and interpret the 7-bit representation explained above correctly, you can see that all condition codes must start with a 0. That immediately throws out “always execute”. So every instruction you encode will be conditional. Furthermore, your Rd register always starts with a 0, pain in the ass but not something you can’t bypass. Basically you can only write to half the registers, bummer. Consider the compare functions, these require all a non-ASCII character. Whoops, no comparisons for you. To finish off with, the ADD instruction. The values you can add are constrained by the requirement that they do not include ASCII values below 0x30, so depending on what operand you choose you can only pass in certain values. To sum it up, you can’t use most of the instructions, write to most of the registers and your immediate operands are sharply constrained. Nevertheless the exploit is something that should be taken care off, but not something that should keep you awake at night.

Advertisements

One comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s