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.