IPA Technical Watch Reports on Threats to Smartphones and How to Address Them

～ Looking at the Actual Status and Challenges of Android Device Vulnerability Countermeasures, Derived from IPA's Inspection ～

1

IPA Technical Watch：Reports on Threats to Smartphones and How to Address Them ～ Looking at the Actual Status and Challenges of Android Device Vulnerability

Countermeasures, Derived from IPA's Inspection ～ Contents Summery of this Report ............................................................................................................................. 2 1. Rapid Permeation of Smartphones and Rise of Android Device ...................................................... 3 2. Need of Countermeasures against Smartphone Vulnerabilities...................................................... 4

2.1. Smartphones Have Security Flaws (Vulnerabilities) as PCs do ............................................... 4 2.2. Vulnerabilities in Android Device ............................................................................................... 5

3. Countermeasures Currently Taken against Android Device Vulnerabilities ................................. 6 3.1. Inspected Vulnerabilities ............................................................................................................. 6 3.2. Android Device Vulnerability Countermeasure Status Inspected by IPA ............................... 6

4. Challenges in Android Device Vulnerability Countermeasures ....................................................... 8 4.1. Differences in Vulnerabilities Countermeasures Between a Commercial OS for PC and Android OS .............................................................................................................................................. 8

5. IPA's Approach for Promoting Android Device Vulnerability Countermeasures .......................... 11 Appendix I：Android OS Vulnerabilities Exploited by DroidDream .................................................... 12

(a) Vulnerabilities Exploited by DroidDream ..................................................................................... 12 (b) Security Mechanism of Android OS ............................................................................................... 13 (c) Damages Caused When this Vulnerability Was Exploited ........................................................... 14

Appendix II：Description of Vulnerability [A] and [B] (For Those in Charge of Information Security) .................................................................................................................................................................... 15

(a) Vulnerability [A]: Vulnerability in Linux Kernel Module "udev" (CVE-2009-1185) ................... 15 (b) Vulnerability [B]: Vulnerability in Android Development Tool "adb" (CVE-2010-EASY) .......... 15

Revision History ........................................................................................................................................ 16

2

IPA Technical Watch：Reports on Threats to Smartphones and How to Address Them ～ Looking at the Actual Status and Challenges of Android Device Vulnerability Countermeasures,

Derived from IPA's Inspection ～

June 22, 2011 INFORMATION-TECHNOLOGY PROMOTION AGENCY, JAPAN

IT SECURITY CENTER

Summery of this Report Unlike traditional cell phones, smartphones allow users to add new functions or expand existing functions by installing application software, as done with PCs. So it's not an exaggeration to say that smartphones are "a PC with telephone function".

Given that several vulnerabilities have been reported on Android OS whose market share has been boosting in recent years, IPA conducted an inspection of some domestically-available Android devices to find out the actual status and challenges of their vulnerability countermeasures.

The inspection was conducted in March 2011 against 14 models of Android devices commercially available as of March 2011, using some part of the program that comprises a virus called "DroidDream". DroidDream exploits two vulnerabilities in Android OS that were uncovered in August 2010. The purpose of this inspection was to confirm each model's countermeasure status regarding those vulnerabilities.

By the time of the inspection in March 2011, those two vulnerabilities in Android OS had reportedly been remedied; however, the March inspection reveled that among the 14 models, 11 (about 79 percent) had not been fixed yet. At some interval, in June, we inquired the distributors of those models about their vulnerability remediation status and found that two models had not been fixed yet.

In this way, even ten months after the detection of those vulnerabilities, there are some models that haven't been fixed yet. Since Android device manufactures customize the Android OS provided to meet their own specification for individual models, even if a security patch for the OS is released, it could take time in adopting it to their customized OS.

Meanwhile, numerous vulnerabilities have been found in its underlying open source software as well, but because device manufactures add their own specification to it, it is difficult for users to determine which vulnerability is affecting which model and whether certain vulnerability is remedied on their device.

Because of their pervasiveness in the world, use of open source software as their base, and flexibility in application distribution, etc., vulnerabilities in Android OS are easily targeted by attackers. So, a mechanism for rapidly exchanging information among device manufactures and security software firms, etc. is required, rather than each manufacture trying to expand and improve their countermeasures. Such efforts are already underway in our country and IPA plans to provide information to and exchange information with enterprises/organizations dealing with smartphones so that those challenges are overcome.

3

1. Rapid Permeation of Smartphones and Rise of Android Device

In recent years, we saw a rapid permeation of smartphones (in particular, Android-equipped ones). According to a survey conducted by Gartner1 in the U.S, global shipment of smartphones in 2010

reached 300 million units (72 percent increase over the previous year's). And according to "a survey conducted by MM Research Institute2 , 8.55 million of smartphone units were shipped in Japan in 2010, up about 3.7 fold from a year earlier and accounting for 22.7 percent of the global shipment.

By operating systems, Nokia's Symbian accounted for 37.6 percent of all the units shipped worldwide, followed by Google's Android OS at 22.7 percent（Figure 1, on the left side）. Meanwhile, Android OS has the largest market share in Japan （Figure 1, on the right side））. According to Gartner, market share of Android OS is expected to reach 49.2 percent in 2012, which means the share of Android device in the smartphone market is expected to increase after 2011.

57.4

37.6

22.7

16.0

15.7

4.2 3.8

Symbian

Android OS

BlackBerry

iOS

Windows Mobile

Others37.8

Source: Gartner in the U.S (IPA made this chart based on the published values) Source: MM Research Institute in Minato ward, Tokyo

Figure 1: Breakdown of Smartphone OSs (YR 2010)

According to a survey on enterprises' IT investment trend conducted by GfK Marketing Service

Japan Ltd in 20103, as of 2010, among 1600 domestic enterprises, those introducing smartphones accounted for only ten percent while those answered "Considering introducing them" or "Have an interest" accounted for about 40 percent. Smartphones are expected to be used also for corporate activities after 2011.

1 http://www.gartner.com/it/page.jsp?id=1543014 2 http://www.m2ri.jp/newsreleases/main.php?id=010120110510500 (in Japanese) 3 http://www.gfkjpn.co.jp/update_file/pdf/246.pdf (in Japanese)

4

2. Need of Countermeasures against Smartphone Vulnerabilities 2.1. Smartphones Have Security Flaws (Vulnerabilities) as PCs do

As the same as PC, smartphones have security flaws (vulnerabilities). In the case of traditional, domestic cell-phones, OS and software being used varied depending on

the model and they were mainly used in Japan. So, even if a vulnerability was exploited, the extent of the impact was limited, resulting in low-margin for the attacker and less serious problem. But things change when it comes to smartphones. As the same as PC, they use an universal OS and software whose vulnerability exploitation could lead to an extensive damage and much greater benefits for the attacker（Figure 2）.

OS and software vary depending on the model

Universal OS and software are used in devices produced at both home and abroad by many different manufactures

Easily targeted by the attacker

Traditional, domesticcell-phone

Smartphone PC

An identical device is used worldwideAn identical device is used within Japan

Attacker

Software used

Provisioning ofhardware

Figure 2: As the Same as PC, Smartphones are Targeted

In fact, several incidents involving smartphones vulnerability exploitation have occurred since

August 20104. Since smart pones are expected to be used for both personal use and corporate activities, there is an increasing risk of their OS vulnerabilities being exploited. For smartphones, PC-equivalent vulnerability countermeasures are required.

4 How to exploit iPhone and other iOS devices is demonstrated at the Website JailbreakMe (August,

2010); there are also some viruses that exploit Android OS vulnerabilities, as represented by DroidDream that was found in March 2011 and is described in this report.

5

2.2. Vulnerabilities in Android Device

Android OS was developed from Linux kernel which is an open source software. This OS is generally customized by device manufactures and built it into their devices (Details are discussed in "4.1 Differences in Vulnerabilities Countermeasures Between a Commercial OS for PC and Android OS". Phone users can freely install Android applications to expand their phones' feature. In any of these cases, vulnerabilities could be introduced.

As of June 21 2011, 17 pieces of Android-device-related vulnerability countermeasure information had been stored in JVN iPedia - Vulnerability Countermeasure Information Database – provided by IPA. Vulnerabilities that affect Android device include those in Linux kernel. If any vulnerability is found in Linux kernel, it may also affect Android OS （vulnerability (1) in Figure 3）. Because Android OS versions vary depending on the model, even if a vulnerability is remedied for a specific OS version, some models may remain unfixed. Let's look at vulnerability (2) in Figure 3; while Android model (C) is fixed, other models (i.e., (a) and (b)) remain unfixed. This situation makes it difficult for phone users to determine which vulnerability is affecting which model and whether certain vulnerability is remedied on their device.

DroidDream which was confirmed in March 2011 exploits two vulnerabilities in Android OS (hereinafter referred to as vulnerability [A] and [B], for more details, refer to Appendix I). So there was an urgent need to check for each model's vulnerability countermeasure status.

For this reason, IPA inspected each Android model's countermeasure status regarding vulnerability [A] and [B] and clarified actual status5.

Android devicemodel (a)

Linux kernel(Open source software)

Android OS

Customized part(varies depending on the

Android device model)

Android app. (a)

Android devicemodel (b)

Android app. (b)

Android devicemodel (c)

Android app. (c)

(1) and (2) indicate vulnerability

(2) (2) (2)

(1)

Figure 3: Vulnerabilities in Android Devices

5 CVE(Common Vulnerabilities and Exposures) identifier of vulnerability [A] and [B] is "CVE-2009-1185"

and "CVE-2010-EASY", respectively. For more details on these two vulnerabilities, refer to Appendix II.

6

3. Countermeasures Currently Taken against Android Device Vulnerabilities 3.1. Inspected Vulnerabilities

Vulnerability [A] and [B] that were exploited by DroidDream were found in August 20106and reportedly eliminated in Android OS version 2.2.2 or newer versions, according to Google's public announcement7.

These two vulnerabilities can only be exploited by an Android application running on an Android device. This means that, it is impossible for an attacker with malicious intent to directly attack an Android device via the Internet through the exploitation of these vulnerabilities. As long as the Android device can prevent the infection of a virus that exploits these vulnerabilities, it is less likely to receive an attack from an attacker. We consider that, even if your Android device has not been fixed against vulnerability [A] and [B], as long as you can prevent the infection of a virus that exploits these vulnerabilities, you are less likely to suffer direct damages caused by such attack.

3.2. Android Device Vulnerability Countermeasure Status Inspected by IPA IPA inspected vulnerability countermeasure status of some domestically-available Android devices regarding vulnerability [A] and [B].

The March 2011 inspection reveled that among the 14 models inspected, 11 (about 79 percent of the model surveyed) had not been fixed yet（See the "Result of the Inspection by IPA (March 2011)" column in Figure 4）. IPA informed the distributors of those models about its inspection result and inquired them about actual status. Then two models (19 percent of the models surveyed) were turned out to be unfixed.

We also learned from the distributors that some of the models marked "Unfixed" had actually been fixed by March 2011. As far as these models are concerned, there are differences beteween IPA's findings and actual countermeasures status. We assume that there were some problems with updating those Android models to the latest version on IPA's side and confirmed such problems with "IS01". <IPA's Inspection on Android Devices' Vulnerability Countermeasures Status> [Subject] Domestically-available Android devices: 14 models8 * Prior to the inspection, all the models had been upgraded to the latest version provided by the

Android device manufactures (as of the end of March, 2011). [Period] March 17 - June 7, 2011 Implementation Period for Method (1) and (2): March 17-31, 2011 Implementation Period for Method (3): from the completion day of Method (2) through June 7, 2011

6 Vulnerability [A] is, in fact, a vulnerability in Linux kernel that was reported in April 2009. In August 2010,

it was found to affect Android OS. 7 http://googlemobile.blogspot.com/2011/03/update-on-android-market-security.html 8 IPA used these verifiable models from commercially available, domestic Android terminals (as of early

March 2011).

7

[Method] (1) Execute on each Android model an exploit code9 for vulnerability [A] and [B]. Based on the

execution result, mark the "Fixed" or "Unfixed". If failed: "Fixed" If successful: "Unfixed"

(2) Categorize each model into "Fixed", "Partly fixed", or "Unfixed" as follows:

If both of the vulnerabilities has been remedied：[Fixed] If either of them has been remedied：[Partly fixed] If neither of them has been remedied：[Unfixed]

This result is reflected in the "Result of the Inspection by IPA (March 2011)" column in Figure 4.

(3) Communicate the distributors of those 14 models about the results in the above (2) and confirm actual countermeasure status.

This result is reflected in the "Countermeasure Status (June 2011)" column in Figure 4. [Result]

001HT 2.2 Partly fixed FixedReportedly fixed in May 2011.The latest version: 2.3

003SH 2.2.1 Partly fixed Fixed Reportedly fixed in Feb. 2011.

003Z 2.2 Partly fixed Partly fixed Planned to be fixed in the future.

IS01 1.6 Unfixed Fixed Reportedly fixed in Mar. 2011.

IS03 2.1 Fixed FixedReportedly fixed in Jan. 2011.The latest version: 2.2.1

IS05 2.2 Fixed Fixed Reportedly fixed prior to its release.

IS06（SERIUS α） 2.2.1 Fixed Fixed Reportedly fixed in Feb. 2011.

ISW11HT（HTC EVO WiMAX） 2.2 Partly fixed Partly fixed Planned to be fixed in the future.

SC-01C（GALAXY Tab） 2.2 Unfixed Fixed Reportedly fixed in Jun. 2011.

SC-02B（GALAXY S） 2.2.1 Unfixed Fixed Reportedly fixed in Jun. 2011.

SH-03C（LYNX 3D） 2.2.1 Partly fixed Fixed Reportedly fixed in Jan. 2011.

SMT-i9100 2.2 Partly fixed FixedReportedly fixed in Jun. 2011.The latest version: 2.2.2

SO-01B（Xperia） 2.1.1 Unfixed Fixed Reportedly fixed in Jan. 2011.

T-01C（REGZA Phone） 2.1.1 Partly fixed Fixed Reportedly fixed in May 2011.

Resu lt o f the

In spec t ion by IPA

(March 2011 )RemarksMode l name

Version

(at the t ime o f

in spec t ion )

Coun te rmeasu re

status

(June 2011 )

(*1) As for IS01, we confirmed that there were some problems with updating those models to the latest version.

Figure 4: Inspection Result on Vulnerability Countermeasure Status of Android Device 14 Models

Vulnerability countermeasure status in Figure 4 is not the latest one but the one at the time of releasing this report. For the latest countermeasure status regarding vulnerability [A] and [B], be sure to visit the following URL: http://www.ipa.go.jp/security/english/vuln/android_vuln/

9 This refers to a publicly-available program designed to demonstrate that certain vulnerability is

exploitable, or its source code. The exploitation code used in this inspection is part of the program that comprises DroidDream.

8

4. Challenges in Android Device Vulnerability Countermeasures

The reality is, there are some Android models that have not been fixed yet even ten months after the detection of those vulnerabilities, as described in "3.2 Android Device Vulnerability Countermeasure Status Inspected by IPA". The thing is, vulnerability countermeasures applied to a commercial OS for a PC and those applied to Android device are basically different.

4.1. Differences in Vulnerabilities Countermeasures Between a Commercial

OS for PC and Android OS [vulnerability countermeasures applied to a commercial OS for a PC] For example, in the case of Microsoft's Windows OS and Apple's MacOS, vulnerabilities are remedied by their developers and security patches distributed over a network; so users only need to apply them to fix those vulnerabilities. This is possible because a commercial OS is built into a PC without customization.

Let's think about a manufacture's PC equipped with Microsoft's Windows. First, Microsoft develops Windows to be built into a PC. Then a PC manufacture equips their PCs

with the developed Windows and ship them to sales agents and electronics retail stores. And finally, consumers purchase those Windows PCs（Figure 5）.

In the case of Windows PCs, the operating system developed by its developer is used by the user without customization. This enables a simple mechanism: "the developer remedies any vulnerabilities found and the user applies a security patch provided."

If any vulnerability is found in Windows, the OS developer (i.e., Microsoft) remedies it, for example, within one month, for which any Windows PC can have the vulnerability eliminated.

Development Manufacturing Use

OS developer PC manufacture PC user

Company A

Company B

Company C

* The operating system developed by its developer is built into a manufacture’s PC without customization. This figure does not include a home-built PC (i.e., the one that the user purchases individual parts and self-assemble them.)

Distribution

Figure 5: Outline Drawing for the Development, Manufacturing, Distribution, Use of Windows PCs

9

Let's think about a PC equipped with Apple's MacOS; unlike Windows PCs, the OS developer and

the PC manufacture is identical (i.e., Apple) （Figure 6）. But as the same as Windows PCs, the operating system developed by its developer is used by the

PC users without customization, which also enables a simple mechanism: "the developer remedies any vulnerabilities found and the user applies a security patch provided."

PC manufacture(Doubles as OS development and PC manufacturing) PC user

* The PC manufacture develops an operating system by itself and build it into their PCs.

Development Manufacturing UseDistribution

Figure 6: Outline Drawing for the Development, Manufacturing, Distribution, Use of Mac OS PCs

Some types of smartphones such as Apple's iPhone and Research In Motion's BlackBerry has the

distribution mechanism illustrated in Figure 6, so users can easily fix their phones' vulnerabilities. Note, however, that vulnerability countermeasures applied to Android device are different from

those applied to a commercial OS for a PC.

10

[Vulnerability Countermeasures Applied to Android OS] Android OS is developed as open source software under the Open Handset Alliance (OHA). Taking into account the capacity and specifications of their devices, manufactures select an appropriate Android OS version, customize it, and build it into their Android devices. In this way different versions of customized OSs are shipped to users（Figure 7）.

Because of this, the above-mentioned simple mechanism does not apply (i.e., "the developer remedies any vulnerabilities found and the user applies a security patch provided".)

In the case of Android device, when a vulnerability is fixed, device manufactures need to reflect

the fixed part on their customized OS. So even if the OS vulnerability in question was remedied by the OS developer (i.e., OHA) within one month, incorporating time may very depending on the manufacture. For example, while company A may finish it in one month, Company B and C may take three months and six months, respectively, which is considered a significantly-delayed response.

For some Android models, it might not be possible to upgrade their OS to a newer version due to hardware restrictions, leaving the vulnerability un-remedied. For this reason, some manufactures are taking extra measures to mitigate damages10.

OS developer（OHA：Open Handset

Alliance） Device manufacture Device user

Company A

Company B

Company C

* The operating system developed by the developer is customized by each device manufacture.* The customized operating system with many different versions is built into each manufacture’s Android device.

Customizes

Customizes

Customizes

Development Manufacturing UseDistribution

Figure 7: Outline Drawing for the Development, Manufacturing, Distribution, Use of Android Device

10 According to the survey conducted by IPA, there were some Android models whose Android OS

version was older than 2.2.2 but marked as "Fixed". We consider that extra measures were taken by their manufactures to prevent abuse of those vulnerabilities.

11

5. IPA's Approach for Promoting Android Device Vulnerability Countermeasures

With the goal of promoting Android device vulnerability countermeasures, IPA plans to implement the following measures: Measure (1): Sharing information with other organizations

Promotes the development of Android device vulnerability countermeasures by sharing information with other organizations working with smartphones information security (including Android OS-equipped ones); participates in Japan Smartphone Security Forum (JSSEC）as a observer, provides information to and shares information with Mobile Computing Promotion Consortium (MCPC） , organizations working with smartphones information security and enterprises developing security software for smartphones; upon receiving a report on a smartphone vulnerability (including those equipped with Android OS) under the Information Security Early Warning Partnership, encourages the developer of that smartphone to remedy the reported vulnerability.

Measure (2): Collecting and publishing smartphones vulnerability countermeasure information Collects vulnerability information related to smartphones11 and publishes that information on JVN iPedia - Vulnerability Countermeasure Information Database( http://jvndb.jvn.jp/ ). IPA is already working on it 12 and as of June 21, 2011, 295 pieces of smartphone-related vulnerability countermeasure information had been stored in JVN iPedia. Figure 8 below shows how to search vulnerability countermeasure information for Android OS.

(1)Type in the keyword “Android” and click the search button.

(2)Vulnerability countermeasure information related to Android is displayed.

http://jvndb.jvn.jp/(English: http://jvndb.jvn.jp/en)

If you want to search vulnerability countermeasure information related to non-Android devices, change the keyword to “iOS”, “BlackBerry”, etc.

Figure 8: Searching vulnerability countermeasure information for Android OS on JVN iPedia

11 The information provided is based on the vulnerability information stored in National Vulnerability

Database (NVD) in the U.S. 12 http://www.ipa.go.jp/security/vuln/report/JVNiPedia2011q1.html (in Japanese)

12

Appendix I：Android OS Vulnerabilities Exploited by DroidDream

March 2011, DroidDream13, a Bot virus that exploits Android OS's weakness (hereinafter referred to as vulnerability) was confirmed14. Although DroidDream does not cause major damage, it proved that Android OS vulnerability is exploitable. If a vulnerability in Android OS is exploited, Android device itself may be rendered unusable or other real damages might be brought to the device user. Google has already removed DroidDream from the Android Market it operates.

For this reason, as of the issuance of this report, it is less likely that an Android device accessing the Android Market is infected with DroidDream.

(a) Vulnerabilities Exploited by DroidDream

DroidDream exploited vulnerability [A] "CVE-2009-1185" and vulnerability [B] "CVE-2010-EASY"15 in Android OS, both of which allows for privilege escalation. By exploiting these two vulnerabilities (hereinafter referred to as a vulnerability for privilege escalation), DroidDream can operate Android OS with a higher level of privilege than those granted to ordinary Android applications (hereinafter referred to as Android app.). As a result, DroidDream can perform operations on a file which an Android app. cannot read or write.

13 This may be called differently depending on the antivirus software vendor. 14 After August 2010, viruses that target Android OS have been confirmed. For more details on viruses

that target Android OS, refer to the security alert issued by IPA in January 2011 at: http://www.ipa.go.jp/security/topics/alert20110121.html (in Japanese)

15 CVE(Common Vulnerabilities and Exposures) identifier of this vulnerability was not assigned by MITRE in the U.S. Since "CVE-2010-EASY" was outputted as a result of executing an attack code that exploits this vulnerability, it has been recognized as this vulnerability's CVE identifier.

13

(b) Security Mechanism of Android OS

We consider that the security mechanism of Android OS motivated the creator of DroidDream to exploit such vulnerability that allows for privilege escalation.

An ordinary Android app. can only perform the operations permitted by the device user（Figure 9）. Without the user's permission, it cannot operate the system files of Android OS or Android device's hardware (built-in camera, GPS, wireless LAN feature, etc.) If an Android app. wants to perform operations on them, it need to specify those operations in "Permissions". Only after the user approves those operations, can he/she install that Android app.

Androiddevice user

Android OS

Android app.

A file saved by Android app.

Android’ssystem file

Telephone

GPS“Permissons”

Reading/writinga file

OperatingAndroid device

Figure 9: Normal Operation of an Android Application

But if, as done by DroidDream, a vulnerability for privilege escalation is exploited, not only the

operations specified in "Permissions", but also other operations requiring a higher level of privilege may be performed.

For example, Android's system files that Android app. cannot read/write in general might be accessed, or telephone and GPS feature might be operated illicitly despite not being included in "Permissions"（Figure 10）.

Android device user

Android OS

DroidDream“Permissons”

Exploit avulnerability

Reading/writingsystem files

Unauthorized use ofAndroid device

Reading/writinga file

OperatingAndroid device

A file saved by Android app.

Android’ssystem file

Telephone

GPS

Figure 10: Behavior of an Android Application Infected through a Vulnerability Exploitation

14

(c) Damages Caused When this Vulnerability Was Exploited

If a vulnerability for privilege escalation was exploited, the following damages could be produced. Compared to a virus or an attack that does not exploit this vulnerability, those exploiting this vulnerability could produce far more serious damages. Android device might be rendered unusable

Normally, Android app. cannot delete system files. But if this vulnerability was exploited, the system files of Android OS might be deleted. If such system files are deleted, Android OS does not work properly.

Information stored on Android device might be tampered and leaked Even if an Android app. had a permission, it cannot directly read or change the information managed by other Android app.16 But if this vulnerability was exploited, all the information stored on the Android device by its user might be read or tampered.

Android device might be used by a third party without permission

Android app. can only perform the operations on the Android device that are specified in its "Permissions". But if this vulnerability was exploited, other operations that are not included in "Permissions" might be performed. Such operations include, for example, installing an application without the user's permission; and covertly making an outgoing call.

16 In some cases, however, a piece of information that is under the control of an Android app. can be

accessed by other Android app with certain permission granted (e.g., contact information).

15

Appendix II：Description of Vulnerability [A] and [B] (For Those in Charge of

Information Security) (a) Vulnerability [A]: Vulnerability in Linux Kernel Module "udev"

(CVE-2009-1185) Overview

"udev" is a module that comes with Linux Kernel 2.6 or newer versions and used to dynamically create a device file. This was found to have a vulnerability concerning netlink message.

"udev" enables dynamic device node management that is based the kernel's hotplug supporting mechanism through the API functions executed from the user space. Based on the netlink message passed between kernel space and user space, it performs operations on the block device file.

Because "udev" does not check where a netlink message originates from, it might process a netlink message from the user space as the one from the kernel space.

If this vulnerability was exploited by an attacker, the root privilege might be taken over and further attacks carried out.

References CVE

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1185

National Vulnerability Database http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1185

INTREPIDUS GROUP http://intrepidusgroup.com/insight/2010/09/android-root-source-code-looking-at-the-c-skills/

(b) Vulnerability [B]: Vulnerability in Android Development Tool "adb" (CVE-2010-EASY) Overview

A tool called "adb" that is included in SDK for Android was found to have a vulnerability concerning shell command execution.

"adb" enables users to execute shell commands against, or transfer a file to, a device or an emulator.

"adb" has a flaw in its process-related check that allows anyone to issue the setuid command to gain the root privilege and to execute arbitrary shell commands with the root privilege. If this vulnerability was exploited by an attacker, the root privilege might be taken over.

References INTREPIDUS GROUP

http://intrepidusgroup.com/insight/2010/09/android-root-source-code-looking-at-the-c-skills/

.dtors http://dtors.org/2010/08/25/reversing-latest-exploid-release/

thesnkchrmr http://thesnkchrmr.wordpress.com/2011/03/24/rageagainstthecage/#more-4

16

Revision History Date of Update Description Jun. 22, 2011 Published Sep. 13, 2011 Parts of sentences in page 6 revised

Parts of Figure 4 in page 7 revised