안드로이드 Platform : Porting / Devices / Source / CTS / TV / GMS 
Multiple vulnerabilities in Google's Android SDK
작성자
작성일 2008-03-09 (일) 01:40
ㆍ추천: 0  ㆍ조회: 3096      
IP: 221.xxx.120
Multiple vulnerabilities in Google's Android SDK

Core Security Technologies - CoreLabs Advisory
http://www.coresecurity.com/corelabs/

Advisory Information

Title: Multiple vulnerabilities in Google's Android SDK
Advisory ID: CORE-2008-0124
Advisory URL: http://www.coresecurity.com/?action=item&id=2148
Date published: 2008-03-04
Date of last update: 2008-03-04
Vendors contacted: Google
Release mode: Coordinated release

Vulnerability Information

Class: Heap overflow, integer overflow
Remotely Exploitable: Yes (client-side)
Locally Exploitable: No
Bugtraq ID: 28005 28006
CVE Name: CVE-2008-0986 CVE-2008-0985 CVE-2006-5793 CVE-2007-2445 CVE-2007-5267 CVE-2007-5266 CVE-2007-5268 CVE-2007-5269

Vulnerability Description

Android is project promoted primarily by Google through the Open Handset Alliance aimed at providing a complete set of software for mobile devices: an operating system, middleware and key mobile applications [1]. Although the project is currently in a development phase and has not made an official release yet, several vendors of mobile chips have unveiled prototype phones built using development releases of the platform at the Mobile World Congress [2]. Development using the Android platform gained activity early in 2008 as a result of Google's launch of the Android Development Challenge which includes $10 million USD in awards [3] for which a Software Development Kit (SDK) was made available in November 2007.
The Android Software Development Kit includes a fully functional operating system, a set of core libraries, application development frameworks, a virtual machine for executing application and a phone emulator based on the QEMU emulator [4]. Public reports as of February 27th, 2008 state that the Android SDK has been downloaded 750,000 times since November 2007 [5].
Several vulnerabilities have been found in Android's core libraries for processing graphic content in some of the most used image formats (PNG, GIF an BMP). While some of these vulnerabilities stem from the use of outdated and vulnerable open source image processing libraries other were introduced by native Android code that use them or that implements new functionality.
Exploitation of these vulnerabilities to yield complete control of a phone running the Android platform has been proved possible using the emulator included in the SDK, which emulates phone running the Android platform on an ARM microprocessor.
This advisory contains technical descriptions of these security bugs, including a proof of concept exploit to run arbitrary code, proving the possibility of running code on Android stack (over an ARM architecture) via a binary exploit.

Vulnerable packages

  • Android SDK m3-rc37a and earlier are vulnerable several bugs in components that process GIF, PNG and BMP images (bugs #1, #2 and #3 of this advisory).
  • Android SDK m5-rc14 is vulnerable to a security bug in the component that process BMP images (bug #3).

    Non-vulnerable packages

  • Android SDK m5-rc15

    Vendor Information, Solutions and Workarounds

    Vendor statement:
    "The current version of the Android SDK is an early look release to the open source community, provided so that developers can begin working with the platform to inform and shape our development of Android toward production readiness. The Open Handset Alliance welcomes input from the security community throughout this process. There will be many changes and updates to the platform before Android is ready for end users, including a full security review."

    Credits

    These vulnerabilities were discovered by Alfredo Ortega from Core Security Technologies, leading his Bugweek 2007 team called "Pampa Grande". It was researched in depth by Alfredo Ortega.

    Technical Description / Proof of Concept Code

    Android is a software stack for mobile devices that includes an operating system, middleware and key applications. Android relies on Linux version 2.6 for core system services such as security, memory management, process management, network stack, and driver model. The kernel also acts as an abstraction layer between the hardware and the rest of the software stack.
    The WebKit application framework is included to facilitate development of web client application functionality. The framework in turn uses different third-party open source libraries to implement processing of several image formats.
    Android includes a web browser based on the Webkit framework that contains multiple binary vulnerabilities when processing .GIF, .PNG and .BMP image files, allowing malicious client-side attacks on the web browser. A client-side attack could be launched from a malicious web site, hosting specially crafted content, with the possibility of executing arbitrary code on the victim's Android system.
    These client-side binary vulnerabilities were discovered using the Android SDK that includes an ARM architecture emulator. Binary vulnerabilities are the most common security bugs in computer software. Basic bibliography on these vulnerabilities includes a recently updated handbook about security holes that also describes current state-of-the-start exploitation techniques for different hardware platforms and operating systems [6].
    The vulnerabilities discovered are summarized below grouped by the type of image file format that is parsed by the vulnerable component.
    #1 - GIF image parsing heap overflow
    The Graphics Interchange Format (GIF) is image format dating at least from 1989 [7]. It was popularized because GIF images can be compressed using the Lempel-Ziv-Welch (LZW) compression technique thus reducing the memory footprint and bandwidth required for transmission and storage.
    A memory corruption condition happens within the GIF processing library of the WebKit framework when the function GIFImageDecoder::onDecode() allocates a heap buffer based on the “Logical Screen Width and Height” filed of the GIF header (offsets 6 and 8) and then the resulting buffer is filled in with an amount of data bytes that is calculated based on the real Width and Height of the GIF image. There is a similar (if not the same) bug in the function GIFImageDecoder::haveDecodedRow() in the open-source version included by Android in WebKitLibWebKitWebCoreplatformimage-decodersgifGifImageDecoder.cpp inside webkit-522-android-m3-rc20.tar.gz available at [8].
    Detailed analysis:
    When the process com.google.android.browser must handle content with a GIF file it loads a dynamic library called libsgl.so which contains the decoders for multiple image file formats.
    Decoding of the GIF image is performed correctly by the library giflib 4.0 (compiled inside libsgl.so). However, the wrapper object GIFImageDecoder miscalculates the total size of the image.
    First, the Logical Screen Size is read and stored in the following calling sequence (As giflib is an Open Source MIT-licenced library, the source was available for analysis): GIFImageDecoder::onDecode()->DGifOpen()->DGifGetScreenDesc(). The last function, DGifGetScreenDesc(), stores the “Logical Screen Width and Height” in a structure called GifFileType:



  •  

    We can see that the fields are stored in the first 2 words of the structure:




     

    In the disassembly of the GIFImageDecoder::onDecode() function provided below we can see how the DGifOpen() function is called and that the return value (A GifFileType struct) is stored on the $R5 ARM register:




     

    Then, the giflib function DGifSlurp() is called and the Image size is correctly allocated using the Image Width and Height and not the Logical Screen Size:




     

    Afterwards the “Logical Screen” Width and Height are stored in the R9 and R11 registers:




    However the actual image may be much larger that these sizes that are incorrectly passed to a number of methods of the GIFImageDecoder:




     

    This function stores the SWidth and SHeight inside the Bitmap object as shown in the following code snippet:




     

    And later:




     

    The following python script generates a GIF file that causes the overflow. It requires the Python Imaging Library. Once generated the GIF file, it must be opened in the Android browser to trigger the overflow:




     

    This security bug affects Android SDK m3-rc37a and earlier versions. Version m5-rc14 of the Android SDK includes a fix and is not vulnerable to this bug.
    #2 - PNG image parsing, multiple vulnerabilities:
    The Portable Network Graphics (PNG) is a bitmapped image format that employs lossless data compression [9]. PNG was created to improve upon and replace the GIF format as an image file format that does not require a patent license.
    The library libsgl.so used by Android's WebKit contains commonly used code to load graphic files, as libpng, giflib and others. The version inside libsgl.so distributed with Android SDK m3-rc37a and earlier versions include the string "libpng version 1.2.8 - December 3, 2004". Source code inspection of the file WebKitLibWebKitWebCoreplatformimage-decoderspngpng.c included in the webkit-522-android-m3-rc20.tar.gz release of the Android project reveals that "libpng version 1.2.7 - September 12, 2004" has been used in this release.
    This old version of libpng makes Android SDK m3-rc37a and earlier versions vulnerable to the following known issues: CVE-2006-5793, CVE-2007-2445, CVE-2007-5267, CVE-2007-5266, CVE-2007-5268, CVE-2007-5269 .
    Android version m5-rc14 has been updated to include libpng 1.2.24 and is likely not vulnerable.
    #3 - BMP image processing, negative offset integer overflow:
    The BMP file format, sometimes called bitmap or DIB file format (for device-independent bitmap), is an image file format used to store bitmap digital images, especially on Microsoft Windows and OS/2 operating systems [10].
    The integer overflow is caused when a Windows Bitmap file (.BMP) header is parsed in the method BMP::readFromStream(Stream *, ImageDecoder::Mode) inside the libsgl.so library. When the value of the offset field of the BMP file header is negative and the Bitmap Information section (DIB header) specifies an image of 8 bits per pixel (8 bpp) the parser will try to allocate a palette, and will use the negative offset to calculate the size of the palette.
    The following code initializes the palette with the color white (0x00ffffff) but with a carefully chosen negative offset it can be made to overwrite any address of the process with that value. Because the BMP decoder source wasn't released, a disassembly of the binary included by Android is provided below:




     

    Now, if let's take a look at the memory map of the Android browser:




     

    We can see that the heap is located in the range 0000a000-00c73000 and it is executable. Overwriting this area will allow to redirect execution flow if there is a virtual table stored in the heap. Later on the same method we can see that a call to the "Stream" Object VT is made:




     

    Because the "Stream" Object (R8) is stored on the heap and we can fill the heap with the white color 0x00ffffff we can load the Program Counter with the value at 0xffffff+0x10. The following python script will generate a BMP to accomplish that:




     

    Opening the BMP file generated with this script inside a HTML page will cause (sometimes, as it is dependent on an uninitialized variable) the following output of the gdb debugger:




     

    Here the browser process has jumped to the 0x00000000 address because that is the value at 0x00ffffff+0x10. We can change this value using common JavaScript heap-filling techniques.


    The complete exploit page follows:




     

    Because the exploit needs to fill over 16 MB of heap memory to reach the address 0xffffff it is very slow and the default memory configuration of Android will often abort the process before reaching the desired point. To overcome this limitation for demonstration purposes one can launch the emulator with this parameters:
    emulator -qemu -m 192
    That will launch the Android emulator with 192 megabytes of memory, plenty for the exploit to work.
    This security bug affects Android SDK m5-rc14 and earlier versions.

    Report Timeline

    • 2008-01-30: Vendor is notified that possibly exploitable vulnerabilities where discovered and that an advisory draft is available. This affects Android SDK m3-rc37a and earlier versions.
    • 2008-01-30: Vendor acknowledges and requests the draft.
    • 2008-01-31: Core sends the draft encrypted, including PoC code to generate malformed GIF images.
    • 2008-01-31: Vendor acknowledges the draft.
    • 2008-02-02: Vendor notifies that the software is an early release for the open source community, but agree they can fix the problem on the estimated date (2008-02-25).
    • 2008-02-04: Core notifies the vendor that Android is using a vulnerable PNG processing library.
    • 2008-02-08: Vendor acknowledges, invites Core to send any new findings and asks if all findings will be included in the advisory.
    • 2008-02-12: Core responds to vendor that all security issues found will be included in the advisory, the date is subject to coordination.
    • 2008-02-12: Vendor releases version m5-rc14 of the Android SDK. Core receives no notification.
    • 2008-02-13: Core sends the vendor more malformed images, including GIF, PNG and BMP files. Only the BMP file affects the m5-rc14 release.
    • 2008-02-20: Core sends to the vendor a new version of the advisory, including a BMP PoC that runs arbitrary ARM code and informs the vendor that we noticed that the recent m5-rc14 release fixed the GIF and PNG bugs. Publication of CORE-2008-0124 has been re-=scheduled for February 27th. 2008.
    • 2008-02-21: Vendor confirms that the GIF and PNG fixes have been released and provides an official statement to the "Vendor Section" of the advisory. A final review of the advisory is requested before its release. The vendor indicates that the Android SDK is still in development and stabilization won't happen until it gets closer to Alpha. Changes to fix the BMP issue are coming soon, priorities are given to issues listed in the public issue tracking system at http://code.google.com/p/android/issues .
    • 2008-02-26: Core indicates that publication of CORE-2008-0124 has been moved to March 3rd 2008, asks if an estimated date for the BMP fix is available and if Core should file the reported and any future bugs in the public issue tracking page.
    • 2008-02-29: Final draft version of advisory CORE-2008-0124 is sent to the vendor as requested. Core requests for any additional comments or statements to be provided by noon March 3rd, 2008 (UTC-5)
    • 2008-03-01: Vendor requests publication to be delayed one day in order to publish a new release of Android with a fix to the BMP issue.
    • 2008-03-02: Core agrees to delay publication for one day.
    • 2008-03-03: Vendor releases Android SDK m5-rc15 which fixes the BMP vulnerability. Vendor indicates that Android applications run with the credentials of an unprivileged user which decreases the severity of the issues found
    • 2008-03-04: Further research by Alfredo Ortega reveals that although the vendor statement is correct current versions of Android SDK ship with a passwordless root account. Unprivileged users with shell access can simply use the su program to gain privileges
    • 2008-03-04: Advisory CORE-2008-0124 is published.

    References


    [1] Android Overview - Open Handset Alliance - http://www.openhandsetalliance.com/android_overview.html

    [2] "Android Comes to Life in Barcelona" - The Washington Post , February 11th, 2008 - http://www.washingtonpost.com/wp-dyn/content/article/2008/02/11/AR2008021101944.html

    [3] Android Developer Challenge - http://code.google.com/android/adc.html

    [4] "Test Center Preview: Inside Google's Mobile future" - Inforworld, Feb. 27th 2008 - http://www.infoworld.com/article/08/02/27/09TC-google-android_1.html

    [5] "'Allo, 'allo, Android" - The Sydney Morning Herald, February 26th, 2008 http://www.smh.com.au/news/biztech/allo-allo-android/2008/02/26/1203788290737.html

    [6] The Shellcoder's Handbook: Discovering and Exploiting Security Holes by Chris Anley , John Heasman , Felix Linder and Gerardo Richarte. Wiley; 2nd edition (August 20, 2007) - http://www.wiley.com/WileyCDA/WileyTitle/productCd-047008023X.html

    [7] Graphics Interchange Format version 89a - http://www.w3.org/Graphics/GIF/spec-gif89a.txt

    [8] Android downloads page http://code.google.com/p/android/downloads/list

    [9] Portable Network Graphics (PNG) specification - http://www.w3.org/TR/PNG/

    [10] Bitmap File Structures - http://www.digicamsoft.com/bmp/bmp.html

    About CoreLabs

    CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://www.coresecurity.com/corelabs/.

    About Core Security Technologies

    Core Security Technologies develops strategic solutions that help security-conscious organizations worldwide develop and maintain a proactive process for securing their networks. The company's flagship product, CORE IMPACT, is the most comprehensive product for performing enterprise security assurance testing. CORE IMPACT evaluates network, endpoint and end-user vulnerabilities and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks. Core Security Technologies augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core Security Technologies can be reached at 617-399-6980 or on the Web at http://www.coresecurity.com.

    Disclaimer

    The contents of this advisory are copyright (c) 2008 Core Security Technologies and (c) 2008 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

    PGP/GPG Keys

    This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core_security_advisories.asc.
    덧글 쓰기 0
    3500
    ※ 회원등급 레벨 0 이상 읽기가 가능한 게시판입니다.