What happens when an Android-related vulnerability is published on a website like the CodeAurora Forum? You got it! Security enthusiasts and Android developers around the world try to take advantage of the newly found problem to create an exploit, which can be used to gain advanced access to your device (such as root access or the ability to flash custom images).
This is exactly what happened to CVE-2014-0973, a vulnerability in an Android Bootloader dubbed “Little Kernel (LK)”. We will talk about the specifics of the exploit a bit later, but for now let’s take a look at what the developers have come up with.
XDA Forum Member vortox has managed to implement an exploit based on CVE-2014-0973 and published a tool for the Amazon Kindle Fire HDX series, that can sign custom boot images if you are using an older bootloader version. The key point here is that you don’t need any kind of unlocking or other trickery to make it work – the exploit allows the tool to sign images in a way that they pass the verification stage in the bootloader with flying colors.
The next part of this article will focus on how the exploit works and why it’s quite sad to see this special vulnerability in a piece of modern software, so if you just want to get your hands on the tool as quickly as possible, head over to the original post and sign away.
Ok, so let’s check out the details of CVE-2014-0973. The issue is all about RSA, an encryption standard also used to sign Android boot images. Put shortly, RSA is a public-key cryptosystem where you have two keys, a private key and a public key. Usually the public key (which can be shared with anyone) is used to encrypt a message which then can only be decrypted again with the private key (which is kept private, hence the name). That way two parties can communicate without ever disclosing their private keys, which are required to decrypt.
However, RSA can also be used to verify the contents of a message (or in our world, to “sign” something). In this case, the message gets encrypted with the private key and can then be shared with the receiver. The public key can then be used to decrypt the message and if the decryption works properly, the receiver can be sure that the encrypted contents originate from the original author and aren’t tempered with in any way.
Speaking of tampering, signature verification is a very important feature for all Android OEMs, as it’s essential to verify that a piece of software is indeed from the OEM and not some third party (for example from an XDA developer). So for example, when trying to flash a new boot image on your device, the following happens: the bootloader will look at the digital RSA signature of the image, decrypt it with its public key and therefore make sure that the image was signed by the intended author (the OEM, which is the only one with the matching private key).
The decrypted signature contains a hash value of the boot image data, which then can be used to compare against the actual data that is about to be flashed. So at this point, the bootloader calculates the hash value of the boot image and compares it against the hash it found in the RSA signature. If these two hashes match each other, it is fairly certain (enough for it to be secure by today’s standards) that the contents are not tampered with and that the owner of the private key signed the image. Which basically means that it’s stock software from the OEM that is fine to be flashed.
That part was probably a little bit harder to grasp, so make sure you understood it before continuing.
Now what about the vulnerability, why does it allow us to sign boot images despite the lack of the private key (which only the OEM has)? Well, it turns out that the implementation of the RSA signature verification in the Little Kernel bootloader is flawed. The issue here is that the decryption algorithm doesn’t verify the length of the data it is handling. While this may sound rather innocent, security concerned readers will immediately see the problem. Cryptosystems always need to validate their input data the best way possible, simply assuming the data is “right” makes the whole process wide open to various attacks.
And that’s exactly what happened here. The missing length check enables exploiters to forge a valid signature by adding custom data to the signature which, in turn, makes it look valid to the verification check in the bootloader. Explaining this in detail would go beyond the scope of this article, but at the end are a few links for further reading about the topic.
If you look at the website that published the vulnerability, it first appears that the issue has been made public rather recently, on June 13, 2014, but upon further research you will quickly discover that it’s a bit older. Way older in fact. The original issue dates back as far as 2006, where Daniel Bleichenbacher talked about it on stage of the International Cryptology Conference. Obviously, he wasn’t talking about an Android bootloader there, but he discovered that many RSA signature implementations had the potentially disastrous flaw. Today, almost nine years later, we can still profit from the very old vulnerability as it enables Amazon Fire HDX owners to sign custom boot images which can be used to root the device or flash a custom recovery.
If you want to have a more detailed picture of what is happening behind the scenes, make sure to check out these links: