Mobile device security has become a hot topic in recent years as always-on network connectivity has become widespread for smartphone users. Security holes in the operating system itself are certainly an issue, but the bigger threat seems to come from third-party applications distributed widely through web stores and marketplaces. Although Google's Android platform takes steps to isolate applications from each other and has a rigid permissions system, a series of recent events have called into question whether that security model offers significant protection from malicious third-party code.
An example of a "traditional" take on Android's application security model might be one described at the blog AndroidCentral.com, which contrasts the Android Market with Apple's App Store. First, Apple strictly curates what programs are accepted and made available to consumers through the store, but Google offers no such authoritative policing of the Android Market. On the other hand, Google, like Apple, does have a remote "kill switch" it can use to deactivate rogue applications.
In addition to the distribution models, the two platforms also differ in their application permission systems. Apple alerts the user if application attempts to use "push" services or request the device's location through GPS, which the user must either approve or disapprove on each individual request. Android has a predefined set of permissions, each of which the application must register its intent to use. The user is notified of every application's permission requests at install-time, and can later check the list from a control panel. The list of permissions is quite long and specific, Android defenders might say, and exposing it to the user makes Android Market applications safer than App Store downloads, which are impossible to audit altogether.
Android's application permission model has its detractors, however, more so in recent months since the discovery of two malicious applications. Jackeey was a purported wallpaper application that was believed to relay personal information from phones to a web site in China, and Tap Snake was an arcade-style game that secretly reported the phone's location to be monitored remotely.
The trouble is that both apps requested Internet access through the Android permissions system; they simply used that permission to harvest data secretly and upload it to a third party. Simson Garfinkel described this on the MIT Technology Review site as a granularity problem, because "although Android programs are required to tell the user which permissions they use, that doesn't explain what the apps actually do with these permissions."
Garfinkel went on to detail his experience asking for explanations from developers whose applications seemingly requested permissions that had nothing to do with their intended purpose. A battery-saving wallpaper applications, for example, requested "the ability to modify or delete SD card contents, full Internet access, and the ability to read my phone's state and identity." In only one case did Garfinkel receive a reply from the application developer, who claimed that Internet access was required to register the program.
He pointed Android users to a program called TaintDroid, which is a possible solution that will be presented at the Usenix Symposium on Operating Systems Design and Implementation (OSDI). Developed by a team from Penn State, Duke University, and Intel, TaintDroid allows fine-grained monitoring of personal information and other data accessed by Android applications. TaintDroid logs attempts by applications to access specific private or sensitive information on the phone (phone number, IMEI number, SIM card ID, GPS location, camera, microphone, etc.), records attempts to transmit that information, and sends user notifications detailing the traffic to the phone's home screen toolbar.
The code has not yet been released, but the project says it will be made available under an open source license, and interested users can email the project and ask to be notified about the release. The team explains on the landing page that TaintDroid was not implemented as a stand-alone application for their purposes, but as a ROM customization. When the code is eventually released, however, it may eventually find its way either into a standalone application, or be incorporated into community-maintained Android distributions.
Sam Watkins also argues that too many applications request blanket permissions beyond what they really need, noting that almost all of the top 20 Android Market games request full Internet access and GPS location. But he also points out that although Android does a good job of revealing to the user what permissions an application has requested, Android offers no way for a user to deny individual requests. In short, if you do not like the set of permissions that an application requests, your only recourse is to not install it.
He also points out that although Android "sandboxes" individual applications by running each one under a unique user ID (thus preventing applications from sharing files), all applications have full read access to the phone's flash storage card, which is used as a general data storage location. Even worse, for backwards-compatibility reasons, any application can request to use the older Android 1.4 API, giving it write/erase permission over the flash storage — and neither this request nor its consequences are revealed to the user.
None of the preceding privacy violations or attacks require an escalation in privilege; the application requests the permissions it wants, and if the user installs it, he or she is immediately exposed. But Watkins also warns of possible attacks based on gaining root access, citing a demonstration example created by Jon Oberheide.
Watkins recommends two responses to the current situation. First, he suggests voting for issue 10481 on the official Android bug tracker, an enhancement request to implement a method of limiting Internet access. At present, the bug has more than 1300 votes.
Secondly, he recommends installing the Droid Wall firewall application on any Android device. Droid Wall is an iptables configuration tool for Android, building on the Linux kernel's existing packet filtering functionality, and allowing the user to write blacklist and whitelist firewall rules in a simple GUI. Earlier versions of Droid Wall required a separate iptables package to be installed, but since 1.4.0 this has been rolled into Droid Wall itself.
The Droid Wall developers primarily advertise the application as a way to reduce battery and mobile data usage, blocking particular applications from repeatedly using the connection or initiating unwanted transfers. When installed, it automatically collects a list of the other applications installed on the phone, and presents them in a user-friendly checklist; the user can then uncheck any application to block its Internet access. It also allows the user to maintain separate permission lists for WiFi and 3G data connections, and automatically switches between the two rule sets when switching to or from a WiFi hotspot.
The Jackeey and Tap Snake incidents raised the profile of Android security problems a few months ago, and major players in the proprietary desktop security market have swept in to collect: both Norton and Symantec Android-specific security suites were unveiled in recent weeks. Both of these applications tackle common "device" security issues, such as on-disk encryption and securing or retrieving data in the event of device loss or theft. The Norton product targets home users, while Symantec targets enterprise deployments.
Neither one addresses the problems created by Android's all-or-nothing application permission requests or the lack of transparency in how applications exercise those permissions. For that, Droid Wall and (when it becomes available) TaintDroid used in tandem may provide the best protection. The TaintDroid team presents its OSDI paper on Wednesday the 6th of October, but a PDF version is already available on the project team's web site.
The paper makes for interesting reading, including the results of a survey of the permissions exercised by the top 30 Android applications. Many, it seems, request permissions that they never exercise — or at least have not exercised yet. A similar survey conducted by Smobile of more than 48,000 Android applications noted that 21 percent requested permission to read private or sensitive information from the phone, and many others "have the ability to read or use the authentication credentials from another service or application," place calls without user interaction, or other potential security breaches.
Google has not officially responded to the published criticism of the application permission system in Android. Bug 10481, while it has received a significant number of comments, has not been assigned. Hopefully the widespread release of TaintDroid will at least raise awareness of the issue in the minds of general Android users. In the meantime, at least the availability of the Android source code makes solutions like TaintDroid and Droid Wall possible.
|Created:||October 4, 2010||Updated:||August 2, 2011|
|Description:||From the Mandriva advisory:
A denial of service attack against apr_brigade_split_line() was discovered in apr-util
|Package(s):||freetype||CVE #(s):||CVE-2010-3054 CVE-2010-3311|
|Created:||October 5, 2010||Updated:||January 20, 2011|
|Description:||From the Red Hat advisory:
A stack overflow flaw was found in the way the FreeType font rendering engine processed PostScript Type 1 font files that contain nested Standard Encoding Accented Character (seac) calls. If a user loaded a specially-crafted font file with an application linked against FreeType, it could cause the application to crash. (CVE-2010-3054)
It was discovered that the FreeType font rendering engine improperly validated certain position values when processing input streams. If a user loaded a specially-crafted font file with an application linked against FreeType, and the relevant font glyphs were subsequently rendered with the X FreeType library (libXft), it could trigger a heap-based buffer overflow in the libXft library, causing the application to crash or, possibly, execute arbitrary code with the privileges of the user running the application. (CVE-2010-3311)
|Created:||October 6, 2010||Updated:||November 11, 2010|
|Description:||The MIT krb5 daemon can be made to dereference an uninitialized pointer, leading to a crash, and, possibly, arbitrary code execution. See this SecurityFocus entry for more information.|
|Package(s):||libesmtp||CVE #(s):||CVE-2010-1192 CVE-2010-1194|
|Created:||October 5, 2010||Updated:||October 6, 2010|
|Description:||From the Mandriva advisory:
libESMTP, probably 1.0.4 and earlier, does not properly handle a \'\0\' (NUL) character in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408 (CVE-2010-1192).
The match_component function in smtp-tls.c in libESMTP 1.0.3.r1, and possibly other versions including 1.0.4, treats two strings as equal if one is a substring of the other, which allows remote attackers to spoof trusted certificates via a crafted subjectAltName (CVE-2010-1194).
|Created:||October 4, 2010||Updated:||May 17, 2011|
|Description:||From the Mandriva advisory:
Multiple cross-site scripting (XSS) vulnerabilities in GNU Mailman before 2.1.14rc1 allow remote authenticated users to inject arbitrary web script or HTML via vectors involving (1) the list information field or (2) the list description field.
|Package(s):||mantis||CVE #(s):||CVE-2010-2574 CVE-2010-3303|
|Created:||September 30, 2010||Updated:||November 9, 2012|
CVE-2010-2574: Cross-site scripting (XSS) vulnerability in manage_proj_cat_add.php in MantisBT 1.2.2 allows remote authenticated administrators to inject arbitrary web script or HTML via the name parameter in an Add Category action.
CVE-2010-3303: XSS vulnerability when uninstalling maliciously named plugins; Multiple XSS issues with custom field enumeration values; XSS issues when using custom field String values; XSS in print_all_bug_page_word.php when printing project and category names
|Package(s):||mysql||CVE #(s):||CVE-2010-3676 CVE-2010-3677 CVE-2010-3678 CVE-2010-3679 CVE-2010-3680 CVE-2010-3681 CVE-2010-3682 CVE-2010-3683|
|Created:||October 5, 2010||Updated:||January 19, 2011|
|Description:||From the Fedora advisory:
Bug #628660 - CVE-2010-3676 MySQL: mysqld DoS (assertion failure) after changing InnoDB storage engine configuration parameters (MySQL bug #55039) https://bugzilla.redhat.com/show_bug.cgi?id=628660
Bug #628040 - CVE-2010-3677 MySQL: Mysqld DoS (crash) by processing joins involving a table with a unique SET column (MySQL BZ#54575) https://bugzilla.redhat.com/show_bug.cgi?id=628040
Bug #628172 - CVE-2010-3678 MySQL: mysqld DoS (crash) by processing IN / CASE statements with NULL arguments (MySQL bug #54477) https://bugzilla.redhat.com/show_bug.cgi?id=628172
Bug #628062 - CVE-2010-3679 MySQL: Use of unassigned memory (valgrind errors / crash) by providing certain values to BINLOG statement (MySQL BZ#54393) https://bugzilla.redhat.com/show_bug.cgi?id=628062
Bug #628192 - CVE-2010-3680 MySQL: mysqld DoS (assertion failure) by using temporary InnoDB engine tables with nullable columns (MySQL bug #54044) https://bugzilla.redhat.com/show_bug.cgi?id=628192
Bug #628680 - CVE-2010-3681 MySQL: mysqld DoS (assertion failure) by alternate reads from two indexes on a table using the HANDLER interface (MySQL bug #54007) https://bugzilla.redhat.com/show_bug.cgi?id=628680
Bug #628328 - CVE-2010-3682 MySQL: mysqld DoS (crash) by processing EXPLAIN statements for complex SQL queries (MySQL bug #52711) https://bugzilla.redhat.com/show_bug.cgi?id=628328
Bug #628698 - CVE-2010-3683 MySQL: mysqld DoS (assertion failure) while reading the file back into a table (MySQL bug #52512) https://bugzilla.redhat.com/show_bug.cgi?id=628698
|Created:||September 30, 2010||Updated:||July 10, 2012|
From the Red Hat bugzilla entry:
A potential Cross Site Scripting (XSS) vulnerability was found in the PECL APC package in versions prior to 3.1.4
|Created:||October 6, 2010||Updated:||November 23, 2010|
|Description:||The PostgreSQL 9.0.1, 8.4.5, 8.3.12, 8.2.18, 8.1.22, 8.0.26 and 7.4.30 releases fix a potential privilege escalation bug: "The security vulnerability allows any ordinary SQL users with 'trusted' procedural language usage rights to modify the contents of procedural language functions at runtime. As detailed in CVE-2010-3433, an authenticated user can accomplish privilege escalation by hijacking a SECURITY DEFINER function (or some other existing authentication-change operation). The mere presence of the procedural languages does not make your database application vulnerable."|
|Created:||October 4, 2010||Updated:||October 6, 2010|
|Description:||From the Mandriva advisory:
A vulnerability has been found in Qt Creator 2.0.0 and previous versions. The vulnerability occurs because of an insecure manipulation of a Unix environment variable by the qtcreator shell script. It manifests by causing Qt or Qt Creator to attempt to load certain library names from the current working directory.
Page editor: Jake Edge
Next page: Kernel development>>
Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds