Stagefright

Published
September 02, 2015
Type
Info notes

Introduction

In July 2015, mobile security firm 'Zimperium' announced that it had discovered a vulnerability in the Android mobile operating system and named it 'Stagefright'. In their official announcement, 'Zimperium' declare that almost a billion devices were vulnerable, and compared the severity of this bug to that of the infamous Heartbleed bug. Certain articles actually recommended that as a result of this vulnerability, Android users should get rid of their devices. 'Zimperium' publicly disclosed the technical details at the BlackHat conference in August 2015.

Android OS Explained

Android is an Operating System that powers a wide variety of devices ranging from smartphones and tablets to watches, GPS navigation systems and even televisions. Android Open Source Project (AOSP) is what all Android firmware is fundamentally based on. Original equipment manufacturers (OEMs) such as Samsung, LG, HTC and Motorola are able to fork, modify and redistribute the AOSP source code in a way that suits their particular needs, as well as build their own User Interface (for example: Samsung: TouchWiz, HTC: Sense) on top. The Android OS source code is available for download, and AOSP allows individuals to contribute to the project by reporting bugs, or even by contributing to the source code with patches and new features.

What is Stagefright?

Stagefright is a software bug that affects the Android operating system, specifically devices running Android versions 2.2 (released in 2010) and above. The underlying attack exploits vulnerabilities in the Android media playback engine component called "Stagefright", which is a software library used as a backend engine for playing multimedia formats such as MP4. The proof of concept exploit presented by 'Zimperium' introduced a malformed MP4 file triggering a heap overflow. This approach can lead to code execution, which could even result in the downloading of applications onto a device. The severity of the vulnerability is mostly due to:

  • Its wide reach: close to 1 billion devices potentially affected;
  • The uniqueness of the attack vector: MMS (see below);
  • The fact that successful exploitation may have severe consequences: performing arbitrary operations on the target device through remote code execution and privilege escalation.

An article from 'TrendMicro' demonstrates how the same exploit can be implemented through three different attack vectors: through an Application; through a URL; and through an MMS. The MMS attack differs from the URL and Application attack in that there is no need for user interaction and the attacker would simply needs the target mobile number in order to attack the victim.

Open Source Software

The nature of Open Source Software acts like a double-edged sword in terms of security. Linus's law states that: "given enough eyeballs, all bugs are shallow". In other words, the availability of the source code facilitates the discovery and hence the patching of flaws. On the other hand one might argue that if the source code is publicly available then individuals with potentially malicious intent are able to identify weaknesses and flaws that can compromise the security of the software.

The openness of Android lead a major role in the discovery of Stagefright. Researcher Joshua J. Drake from 'Zimperium' was able to dive into the Android source code and discover a number of implementation flaws.

Another concern when dealing with Open Source Software is that even the source code of a patch is openly available. Showing how a bug was fixed essentially discloses the underlying issue which can drastically simplify the process of creating an exploit for that particular bug. 'Zimperium' outlined this problem by stating that even though they accepted to delay a Stagefright RCE exploit demonstration, "because the patches are open-source, many researchers are already working on creating an exploit".

This is not necessarily a problem, provided a proper patching regime is in place. In the case of Stagefright one must consider the complexity involved in patching the ≈ 1 billion Android devices affected by this vulnerability. Fixing the issue in the AOSP source does not result in the problem being fixed on all Android devices. The OEMs are responsible for the maintenance of the open source software they use and must ensure that the patch provided by Google reaches their customers.

Recommendations

Source Code Owners

  • Provide coding standards to all contributors, including secure coding practices
  • Enforce those standards using appropriate tools
  • Ensure several layers of security are in place in order to avoid having a single point of failure and diminish the impact of vulnerabilities
  • Implement vulnerability disclosure programs and incentives
  • Acknowledge and act upon disclosed vulnerabilities in a timely manner
  • Provide an organised patching regime

OEMs

    Security researchers

      Users

      • Always keep software up to date with latest patches
      • In this particular case, until a patch is distributed:
        • Disable auto-read MMS, (link on how to disable)
        • Use security software that is able to prevent, detect, and mitigate such bugs

      Conclusion

      Does this mean that Open source software is not secure, or less secure than closed source? Definitely not! However, security professionals must consider and acknowledge the pros and cons of both approaches.

      This particular vulnerability highlighted several security related issues, and might eventually help improve the security aspect of the Android OS. For example, as a result of this incident, some of the most popular OEMs (Google, Samsung, and LG) will start providing regular monthly over-the-air security updates.

      About "Info Notes" from ENISA

      With the “Info Notes” series ENISA aims at giving the interested reader some background and recommendations about NIS related topics. The background and recommendations are derived from past experiences and common sense, and should be taken as starting points for discussions on possible course of action by relevant stakeholders. Feel free to get in touch with ENISA to discuss or inquire more information on the “Info Notes” series (cert-relations@enisa.europa.eu).

      We use cookies to ensure we give you the best browsing experience on our website. Find out more on how we use cookies and how you can change your settings.

      Ok, I understand No, tell me more