Android Security Issues Emerge
Despite Google's efforts to protect its Android mobile OS from possible security attacks, it seems that issues in the Linux kernel could make the popular OS more vulnerable.
The first serious proof of concept exploit for Android platform was made publicly available last week. The targeted vulnerability, discovered in the Webkit mobile browser platform is already fixed by Google in the latest Android release (2.2 Froyo). According to Google, Froyo is used by 36% of all Android devices, which means that the majority of the devices can still be successfully attacked using the exploit.
A few months ago speakers at the BlackHat and Defcon conferences in Vegas underlined a trend for researching attacks on Android platform.
Though it was quite clear at the time that it is relatively easy to write malicious software for Android, Android's security model, both on and off the device, could protect from any potential attacks.
On the device, the tried-and-tested Linux security model is used to assign unique user names and privileges to every installed application, which allows the application code and the data to be separated and stored safely away from the prying routines of malicious applications.
Off the device, potentially malicious applications installed through Android Market can be easily removed from the Market and from the devices directly by Google, which makes the malware remediation easier as long as rogue applications do not interfere with the uninstallation process.
However, Vanja Svajcer, principal virus researcher in SophosLabs, decided to take a look to a web-based remote security exploit for Android as it was made available by M.J. Keith of Alert Logic.
Vanja claims that the proof-of-concept code is very similar to the typical browser exploit code we often see in malicious webpages attacking desktop-based browsers. The exploit contains a heap spray to fill the memory with the ARM-based shellcode which is reached when the exploit is triggered, due to Webkit's incorrect handling of floating point data types.
Vanja fired up the Android emulator Android SDK and installed the exploit on his test server. This setup mimics the real situation, when the user visits a malicious webpage. The exploit was successful most of the times on versions 2.1 and 2.0.1, but not on Android 1.6, Vanja said.
Though the connection to port 2222 was being made, Vanja could not do much with the Linux shell backdoor at first and had to look at the shellcode functionality with IDA.
"The shellcode is easy to read and with the help of the Android system call table I quickly realized it was a simple reverse connecting shell, which creates a socket and redirects the standard input, standard output and standard error of the Linux shell to the socket," he said.
"Once I realized the shellcode is that simple it was obvious I needed to set a few environment variables before I started exploring the system using the backdoor opened by the exploit and the usual shell commands. The Linux security model kicked in once I tried to access various areas of the system. If we look at the process list, it is clear that the backdoor shell has the same privileges as the browser application," he added.
In Android, every application gets its own user identity and it is not allowed to access the data and sensitive system areas of other applications. The installed applications and the application data is installed in the directory '/data' which was not accessible to a remote shell.
To cause more damage and take complete control over the device, a local privilege escalation exploit is required, Vanja found.
However, recent research by Coverity indicates that the Linux kernel 2.6.32 used by Android 2.2 contains a high number of potentially exploitable vulnerabilities which could be combined with the Webkit exploit.
Although Google fixed the discovered vulnerability in the latest Android release, the question about more than 50% Android devices using vulnerable versions of the operating system remains.
"In addition to that, the kernel issues discovered by Coverity will make things even worse, if they are proven to be serious," Sophos ' researcher added.
If the pressure from the security community continues Google will have to provide some good answers if they have decided not to create an automatic security update mechanism similar to the update mechanisms used in desktop operating systems.
Of course, modern smartphones are just as powerful as the desktop computers of only a few years ago so the requirement for a flexible security update mechanism should not be a surprise for the operating system developers and handset manufacturers.
A few months ago speakers at the BlackHat and Defcon conferences in Vegas underlined a trend for researching attacks on Android platform.
Though it was quite clear at the time that it is relatively easy to write malicious software for Android, Android's security model, both on and off the device, could protect from any potential attacks.
On the device, the tried-and-tested Linux security model is used to assign unique user names and privileges to every installed application, which allows the application code and the data to be separated and stored safely away from the prying routines of malicious applications.
Off the device, potentially malicious applications installed through Android Market can be easily removed from the Market and from the devices directly by Google, which makes the malware remediation easier as long as rogue applications do not interfere with the uninstallation process.
However, Vanja Svajcer, principal virus researcher in SophosLabs, decided to take a look to a web-based remote security exploit for Android as it was made available by M.J. Keith of Alert Logic.
Vanja claims that the proof-of-concept code is very similar to the typical browser exploit code we often see in malicious webpages attacking desktop-based browsers. The exploit contains a heap spray to fill the memory with the ARM-based shellcode which is reached when the exploit is triggered, due to Webkit's incorrect handling of floating point data types.
Vanja fired up the Android emulator Android SDK and installed the exploit on his test server. This setup mimics the real situation, when the user visits a malicious webpage. The exploit was successful most of the times on versions 2.1 and 2.0.1, but not on Android 1.6, Vanja said.
Though the connection to port 2222 was being made, Vanja could not do much with the Linux shell backdoor at first and had to look at the shellcode functionality with IDA.
"The shellcode is easy to read and with the help of the Android system call table I quickly realized it was a simple reverse connecting shell, which creates a socket and redirects the standard input, standard output and standard error of the Linux shell to the socket," he said.
"Once I realized the shellcode is that simple it was obvious I needed to set a few environment variables before I started exploring the system using the backdoor opened by the exploit and the usual shell commands. The Linux security model kicked in once I tried to access various areas of the system. If we look at the process list, it is clear that the backdoor shell has the same privileges as the browser application," he added.
In Android, every application gets its own user identity and it is not allowed to access the data and sensitive system areas of other applications. The installed applications and the application data is installed in the directory '/data' which was not accessible to a remote shell.
To cause more damage and take complete control over the device, a local privilege escalation exploit is required, Vanja found.
However, recent research by Coverity indicates that the Linux kernel 2.6.32 used by Android 2.2 contains a high number of potentially exploitable vulnerabilities which could be combined with the Webkit exploit.
Although Google fixed the discovered vulnerability in the latest Android release, the question about more than 50% Android devices using vulnerable versions of the operating system remains.
"In addition to that, the kernel issues discovered by Coverity will make things even worse, if they are proven to be serious," Sophos ' researcher added.
If the pressure from the security community continues Google will have to provide some good answers if they have decided not to create an automatic security update mechanism similar to the update mechanisms used in desktop operating systems.
Of course, modern smartphones are just as powerful as the desktop computers of only a few years ago so the requirement for a flexible security update mechanism should not be a surprise for the operating system developers and handset manufacturers.
