Android 4.4 rootkit protection with verified boot

Androidkitkat_logoAndroid 4.4 (KitKat) introduces and experimental rootkit protection with verified boot which looks for persistent rootkits that can retain root privileges to compromise your Android device. Rootkits have a tendency to hide themselves in root and avoid being detected by the operating system and any installed security software.

Android apps are installed in the operating system user space with each app being self-contained when run inside a sandbox (virtual container). This approach stops any app from changing files outside of the sandbox or files within another sandbox.

Verified boot through the optional device mapper-verity (dm-verity) kernel feature, provides integrity checking of block Android devices. The dm-verity helps prevent persistent rootkits that hold onto root privileges to compromise a device. dm-verity provides the user with a high-level of assurance that when Android OS boots the device is in the same state as when last used.

Verified boot comes enabled on Android 4.4 (see bootnote). There is a small issue with OTA updates when using dm-verity. OTA works on a file-by-file basis, but dm-verity requires block-orientated OTAs. This block approach servers the Android OTA device the difference between the two block images, rather than two sets of files. Note: Many manufacturers have already moved to block-orientated OTAs, which allow them to have more control of whether the bootloaders on their hardware can be modified. Modders however, will not like this development for obvious reasons.

SELinux has also been improved. On Android 4.3 (Jelly Bean) SELinux only logged privilege escalation attempts but now it uses an enforcing mode that blocks escalation attacks, such as an app attempting to gain root privilege. Most welcome from us security professionals.

Device-mapper-verity and SELinux aim to improve the fragmentation issue, which is a well known problem on the Android platform. Stopping users from modifying their devices is one thing, but carriers delivering timely updates OTA is something else. If the carries are to carry the OTA update burden, they are going to have to communicate with the 25% of devices that currently use Gingerbread 2.3.

My main concern right now is if you decide to upgrade your Nexus 5 (see bootnote) device to the next release of Android, then you will be unable to do so due to dm-verity. It’s possible Google is planning to take ownership of the update process, and if this is the case, fragmentation (and the OTA update issue mentioned here) may be a thing of the past.

There is a compromise to be had between functionality and security. Right now Android is moving in the right direction with a multi layered defence including kernel and hardware security, which if you value your device security and privacy, is the right approach. Modders though will have a different view.

Further reading:

Safe surfing folks!

Bootnote: Analysis of the Nexus 5 bootloader confirms that this is currently unlocked, so hacking the bootloader should be possible.

This entry was posted in android, google, malware, mobile, privacy and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *