The malicious apps threat on Android Jelly Bean 4.1

While I was at Google I/O last month I reported that Android Jelly Bean (version 4.1 and 4.1.1) SD permission security had been strengthened as well as introducing app encryption as part of Google’s app anti-piracy measures. These were much needed improvements not only for developers but also for Android device users. So for the tech readers in droid land I wanted to dig a little deeper to discuss some other Android Jelly Bean 4.1 security developments.

Outside of the above mentioned improvements, Android 4.1 (including 4.1.1) introduced Address Space Layout Randomization (ASLR) (see bootnote) and Data Execution Prevention (DEP). ASLR moves for example critical executables and libraries to random locations. An exploit could occur if key pockets of data are not randomised – in this case an executable for an app. ASLR aims to stop memory corruption attacks often linked to bugs being found in complex pieces of code. DEP on the other hand is designed to prevent a hacker form executing a piece of code that is established to be non-executable. There is a problem with thinking ASLR more of less removes the malware threat though. It doesn’t.

Let us be clear – ASLR is only used to stop exploits. Most Android malware however consists of malicious apps – malware authors repackaging apps with malicious code. Some of these repackaged apps evade detection from Google Bouncer and others are published on third-party app markets. These are generally the infection paths we see today.  So the ASLR security improvement will be unable to stop a malicious app from infecting your Android 4.1 and 4.1.1 devices. Personally, Google should follow Apple’s lead, especially concerning app publishing security. Here is why.

I’ve been saying for the best part of a year now, that Apple is taking the lead with mobile security (outside of RIM). They introduced two code signing practices – one to inspect and verify each app – Apple will only allow an app to install if it has Apple’s certification – so this means only apps from iTunes, with exception to jailbroken devices of course.

Secondly, Apple freezes most apps after an initial inspection so that the app can be run through an algorithm which generates a numeric value. This value is installed on the iOS device along with the app and the device will then generate another value to make certain that the app hasn’t been tampered with. Google hasn’t moved in this direction – yet. Google allows developers to self-sign their own code to verify the code in the app. One can only hope that in time, Google addresses the self-signing issue, due to the ever increasing threat posed by malware authors repackaging apps.

Further reading: Jon Oberhelde’s excellent Android 4.1 mitigation article if you want to learn more about ASLR.

Bootnote: ASLR is available in Ice Cream Sandwich (Android 4.0) but not all pieces of the data were randomized. Apple fully implemented ASLR and DEP into iOS 4.3+.

Safe surfing folks!

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

Leave a Reply

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