Share

Related Links

  • Symantec
  • Reed Exhibitions Ltd is not responsible for the content of external websites.

Related Stories

Top 5 Stories

News

Researcher discovers new Android attack vector

01 July 2011

A Symantec researcher claims to have discovered a new type of Android malware threat in the shape of class loading hijacking, which effectively means that hackers can remotely take over most, if not all, aspects of a smartphone or tablet computer.

According to Mario Ballano of Symantec's research operation, the new attack vector is similar to Windows DLL hijacking and affects a number of Android apps in the official Market resource.

"Bear in mind that we are not talking about Android vulnerabilities per se, but application-specific issues. We found a few applications in the Google Android Marketplace that were susceptible to this attack and have notified the application developers accordingly" he said.

Ballano explained that Android provides application program interfaces (APIs) that allow an application to dynamically load code to be executed.

"For example, an application may support plug-ins that are downloaded and then loaded at a later time. Unfortunately, if these plug-ins are stored in an insecure location, this process can be hijacked, allowing access to private data and unexpected arbitrary code execution by malicious applications", he said.

There are, he asserts, two Android classes that allow the loading for additional code: Public Constructors and DexClassLoader.

The first class, DexClassLoader, he notes, allows an application to load and execute additional DEX code (the code runs within Android' Dalvik virtual machine). The dexPath parameter specifies the file name of the additional DEX code", he says in his latest security posting.

The second class, PathClassLoader, has an issue with the way the operating system looks for additional native libraries, which load when, for example, the API loadLibrary is used.

Typically, says Ballano, these should reside in the secure Android system library path, but the libPath parameter will be searched first, as release prior to Android 2.2 reversed which path was searched initially.

"We discovered additional applications in the Google Android Market that are using this API with the SD card as the libPath parameter. However, since these are Linux binaries and not DEX code, they are subject to additional system permissions", he says,

"In particular, by default, the external storage is mounted with the noexec flag to prevent the execution of any native binaries on the mounted file system, which renders this attack vector useless", he adds.

This means, says the Symantec security researcher, that the developers who specified the SD card did not have an understanding of the purpose of this parameter, since setting it to the SD card simply will not work.

So what's the solution?

Ballano argues that, when loading additional code in Android applications, a developer should ensure that both the loaded code and the generated alternative versions of the code are placed in a secured directory, typically within the application's private directory.

Ideally, he says, DexClassLoader would simply do so by default for dexOutputDir.

"We have contacted Google about these issues, who stated that they will update the developer documentation to remove references to using the insecure SD card location and also advise developers to use a secure directory", he says.

This article is featured in:
Application Security  •  Wireless and Mobile Security

 

Comment on this article

You must be registered and logged in to leave a comment about this article.

We use cookies to operate this website and to improve its usability. Full details of what cookies are, why we use them and how you can manage them can be found by reading our Privacy & Cookies page. Please note that by using this site you are consenting to the use of cookies. ×