Tag Archives: Google Android

Google Releases Security Updates for Android (Feb and March 2016)

On the 7th of March Google released their scheduled security updates for their Android smartphone operating system. That update brings Androids build number to version LMY49H While Android version 6.0 (known as Marshmallow) with Security Patch Level of March 1, 2016 includes the appropriate fixes.

The March updates resolves 19 security vulnerabilities more formally known as CVEs (defined) of the following severities:

====================
7x critical severity CVEs
10x high severity CVEs
2x moderate severity CVEs
====================

Moreover, the previous February updates addresses 13 with the following severities:
====================
7x critical severity CVEs
4x high severity CVEs
2x moderate severity CVEs
====================

That update brings Androids build number to version LMY49G While Android version 6.0 (known as Marshmallow) with Security Patch Level of February 1, 2016 includes the appropriate fixes.

Why Should These Issues Be Considered Important?
For the March update 2 critical vulnerabilities in Mediaserver were fixed that could have allowed an attacker to use email, web browsing or an MMS message (defined) to process media files that would have allowed them to achieve remote code execution (namely to carry out any instructions/actions of their choice). The attacker would only have had to know the victim’s phone number.

Other notable flaws are the Elevation of Privilege in Conscrypt that could allow an attacker to use an invalid digital certificate allowing them to carry out a man-in-the-middle attack (defined).

The critical issue in the Qualcomm Performance Component if exploited would allow an attacker to run code with the privileges of the Android kernel (defined). The same was true of the Kernel Keyring bug. Android version 5.0 and above are however not vulnerable to this flaw if an attempt to exploit comes from 3rd party apps. If these flaws were to be exploited a manual re-flashing (defined) of the operating system would be required to recover from them.

Within the February update a critical issue in the Broadcom Wi-Fi Driver was fixed that could have been exploited by an attacker on the same Wi-Fi network by sending a malicious wireless control message packet (defined) to the phone which would not require any input from the user. The attacker could then run code with the same privileges as the Android kernel. Other critical and high vulnerabilities in the Qualcomm driver and Wi-Fi component respectively could have been exploited by an installed app to run code (have instructions carried out) with system privileges (defined).

How Can I Protect Myself From These Issues?
Updates to resolve these issues were made available by Google on 1st of February 2016 and the 7th of March 2016. Manufacturers such as Samsung/LG etc. received these updates on the 4th of January and 1st February respectively.

As mentioned by Sophos you may need to ask your device manufacturer or mobile carrier when this update will be made available to you. As discussed in a previous post regarding Android updates, please ensure to only apply updates from your mobile carrier or device manufacturer.

You may recall that I discussed the security update process for my Android phone in a previous blog post. An update has been made available by Sony, it’s dated the 8th of March 2016 (notably it’s still Android version 5.0 rather than 6.0). My phone is still using a build of Android from October 2015. I am hopeful to receive this update by the end of the month or very soon afterwards. Sony ‘s website provides release notes for the update which state that it includes “The latest security enhancements”.

Given that Google have released preview versions of the successor to Android version 6.0 (Marshmallow) known as “Nutella” sooner than expected it’s unclear whether Sony will update my phone in the future to Marshmallow or Nutella or simply end-of-life my phone in favor of a newer model. I will update post should my phone receive an update in the near future.

Thank you.

Google Releases Security Updates for Android

In early December 2015 and January 2016 Google made available further security updates for their Android smartphone operating system.

The December update addresses 16 security issues (all of which have been assigned CVE numbers (defined)(4x critical severity, 10x high severity and 2x moderate severity). That update brings Androids build number to version LMY48Z Android version 6.0 (known as Marshmallow) with Security Patch Level of December 1, 2015 or later address these issues. This update includes 2 fixes for security issues within libstagefright (both high severity) and 1 issue within both the Mediaserver (critical severity) and Media Framework (high severity) components.

Meanwhile the January update resolves 12 security issues (all assigned CVE numbers). That update when installed will show build version LMY49F As before, Android version 6.0 (known as Marshmallow) with Security Patch Level of January 1, 2016 or later address these issues. This update includes a fix for a critical issue in the Mediaserver component.

Why Should These Issues Be Considered Important?
As part of the December update a critical issue within Mediaserver was resolved that could be exploited by a remote attacker to allow them to carry out any instructions/actions of their choice (remote code execution). 3rd party applications could then be used to carry out the attacker’s actions with high privileges that they wouldn’t otherwise have. The issue can be exploited by sending specifically crafted media files within MMS messages (defined) or displaying those files on a specifically crafted webpage. Similar critical issues (3 in total) in the Skia graphics engine and Display driver can also use the above 2 means of attack mentioned above in addition to email. The final critical issue would have allowed malicious apps to carry out actions with root privilege (defined) allowing them full control over the smartphone.

For the January update if the MediaServer issue was exploited it could allow an attacker to use any emails, websites or MMS messages containing specifically crafted media files to remotely execute code (i.e. instructions or actions of their choice) due to a memory corruption issue corrected in this update. In addition, the critical issues corrected in the Display Driver (which interacts with high privilege with kernel) and the Android kernel (defined) are serious since the kernel can control any piece of the phones hardware and since it’s the core of the Android operating system it can be used to carry out any action/step since it has the highest level of privilege within the operating system.


How Can I Protect Myself From These Issues?

Updates to resolve these issues were made available by Google on 7th of December 2015 and 4th of January 2016. Manufacturers such as Samsung/LG etc. received these updates on the 2nd of November and the 7th of December respectively.

As mentioned by Sophos you may need to ask your device manufacturer or mobile carrier when this update will be made available to you. As discussed in a previous post regarding Android updates, please ensure to only apply updates from your mobile carrier or device manufacturer.

====
I followed this advice with my very recently purchased Sony smartphone which currently runs Android 5.0 (Lollipop). The Sony website shows that the latest build of Android they offer is already installed on my phone. The build is dated October 2015 (not shown in the image below). They do however show a logo below the build number that appears to suggest that at some time in the future the phone will receive Android 6.0 (Marshmallow). I have attached the image below:

Sony_Update

====
The “Android” name, the Android logo, and other trademarks are property of Google Inc.
Copyright © 2011-2016 Sony Mobile Communications Inc. All rights reserved
====

I also contacted my network carrier and they stated that the device can run these updated versions of Android and that there is no reason why it wouldn’t have received such updates (assuming auto-updates hasn’t been turned off). As I said it appears that I received such updates up to October 2015 (I purchased the phone in November). They stated that Marshmallow will be rolled out in the future but no other details were provided. Neither of these answers are perfect and clearly demonstrate that while updates are being made available by Google and are being provided to the mobile carriers the update process (being used by the mobile carriers) needs to be streamlined for much faster deployment. I hope that you have better luck than I did.

Thank you.

Cisco Issues Security Update to WebEx Android App

Last week Cisco issued a security update for their WebEx Meetings Android App to resolve a severe permissions issue.

Why Should This Issue Be Considered Important?

This is a serious security issue that could lead to information disclosure and an elevation of privilege (defined) attack. It’s present in all versions of the app that are older than version 8.5.1. As Cisco discusses in it’s security advisory this issue could be exploited by a remote attacker with no previous access to the app by tricking the user of the smartphone into downloading another app that exploits this issue within the WebEx app. If this were to happen any information and permissions/access that the WebEx app has will be then available to the malicious app.

In addition, there are no workarounds for this issue. At this time Cisco has not seen any evidence to show that this issue has been used by attackers.

How Can I Protect Myself From This Issue?
Cisco have released an updated version of the WebEx app to address this issue. The updated app is available from this link (Google Play Store). Graham Cluley’s blog post also contains one piece of further important advice to stay safe when downloading apps or app updates.

Thank you.

Further Google Android Stagefright Vulnerabilities Patched

Update: 10th January 2016:
Further updates addressing newer issues within libstagefright have been made available. Please see this more recent blog post for details.

Thank you.

=======================
Original Post:
=======================
In early November Google began rolling out an update to it’s Android smartphone operating system to resolve 7 CVEs (defined)(2x critical severity, 4x high severity and 1x moderate severity). This update brings Android to Build version LMY48X The newest version of Android version 6.0 (known as Marshmallow) also includes these fixes if it’s patch level is dated the 1st of November or later. This update includes 4 fixes relating to more vulnerabilities in Stagefright (discussed in a previous blog post).

Why Should These Issues Be Considered Important?

The 4 issues related to Stagefright were assigned critical and high severity by Google. Such critical flaws will allow an attacker the ability to have the device carry out any instruction they wish (otherwise known as remote code execution). Google provides more specifics in it’s Google Groups post which includes that attackers could try to exploit these flaws when playing back media in a web browser or via an MMS message (defined).

How Can I Protect Myself From These Issues?
Fixes for these issues began to be made available on the 5th of November to Google Nexus devices. Manufacturers such as Samsung received these updates on the 5th of October.

As mentioned by Sophos you may need to ask your device manufacturer or mobile carrier when this update will be made available to you. As discussed in my previous post on Android updates, please ensure to only apply updates from your mobile carrier or device manufacturer.

Thank you.

Google Android Stagefright 2.0 Updates Due To Rollout

Update: 10th January 2016:
Further updates addressing newer issues within libstagefright have been made available. Please see this more recent blog post for details.

Thank you.

=======================
Update: 17th November 2015:
Further updates addressing newer Stagefright issues have been made available. Please see this more recent blog post for details.

Thank you.

=======================

Update: 6th October 2015:
As scheduled Google has begun rolling out the fixes for the Stagefright 2.0 issue. The update named Build LMY48T addresses 30 CVEs (defined)(20x critical, 5x high, 3x moderate, 2x low severity) of which 15 were in libstagefright and 2 were in libutils (which were mentioned in my post below).

Full details are provided by Google in this Google Groups post. As mentioned in my post below, Sophos has provided a comprehensive list of tips to stay safe from these Stagefright 2.0 vulnerabilities.

Thank you.

=======================
Original Post:
=======================
Last week a new set of 2 security vulnerabilities affecting Google’s smartphone operating system Android were disclosed. The same security firm Zimperium that discovered the Stagefright vulnerabilities have found these new flaws and have called them Stagefright 2.0.

The first vulnerability assigned CVE-2015-6602 (CVE, defined) affects versions of Android since version 1.0 from the year 2008. The second vulnerability (not yet assigned a CVE number) is a method to trigger the first flaw in version 5.0 and later of Android.

Why Should These Issues Be Considered Important?
It is estimated that at least one of these new issues is present in approximately 1 billion Android devices. For newer devices remote code execution (where an attacker can remotely trigger code of their choice to carry out any action they choose) is possible using libstagefright within Android version 5.0 and later. For all other devices they may be impacted if 3rd party apps or mobile carrier bundled apps make use of the library libutils when processing specifically crafted MP3 (audio) and MP4 (video) files.

In addition there are 3 further means that these issues could be exploited by an attacker e.g. an attacker on the same network as your Android device could add the exploit to unencrypted traffic using a man-in-the-middle attack (MITM, defined). Moreover an attacker could simply have you visit a malicious website inadvertently using a phishing (defined) email containing a link or a compromised advertisement present on a website of their choice.

The final 2 methods of attack are much likely to occur in practice than the original Stagefright issue (since it relied on older MMS (defined) messages). E.g. a spear phishing (defined) campaign took place in August in an attempt to have users visit a fake Electronic Frontier Foundation site. While in January AOL’s advertising were delivering adverts that exploited the devices that viewed them.

How Can I Protect Myself From These Issues?
Since the disclosure of the original Stagefright issue matters have improved in terms of the speed to respond. A fix for this issue will begin to be made available to Google Nexus devices today. Other manufacturers such as Samsung and LG etc. should follow suit very soon.

Sophos has provided a comprehensive list of tips to stay safe from these Stagefright 2.0 vulnerabilities.

As mentioned by Symantec in this blog post, please ensure to only apply updates from your mobile carrier or device manufacturer.

In addition, Zimperium will be updating their Stagefright Detector app to check if your device is vulnerable to these newer Stagefright issues once updates resolving these issues are made available. This is useful since you can use that app to tell if your device has received the appropriate updates.

Please note that reviews for the Zimperium Stagefright detector app are mixed, thus you may wish to try other apps to check if your device is vulnerable.

Thank you.

Blog Post Shout Out September 2015

Update: 24th November 2015:
Since this blog post was written FireEye have continued to monitor the command and control servers (defined) of XcodeGhost to determine where devices are located that are connecting to these servers and to determine if this malware still poses a threat. They have also found an updated version of XcodeGhost that they have named “XcodeGhost S”.

FireEye have worked with Apple to remove an app from the App Store that was found to be infected with this new variant of the malware.

In addition, an app development firm Possible Mobile has detailed in a blog post how their newly updated app that was built with a verifiably legitimate version of Apple Xcode was being rejected by Apple since their app contained the XcodeGhost malware. It was eventually found that while the code written by Possible Mobile was clean, the third party libraries and frameworks used to provide essential functionality within their app were found to contain the infected code. How Possible Mobile resolved this issue, is detailed in their blog post.

How Can I Protect Myself From This Issue?
In addition to the guidance provided within the blog posts linked to below I would recommend the following:

  1. If you are an app developer and are submitting apps to the Apple App Store it may be worthwhile to follow the steps within Possible Mobile’s blog post concerning validating your copy of Apple Xcode and checking any third party libraries for infection.
  2. As detailed in FireEye’s blog post, for all of the apps installed on your Apple devices, ensure they are the latest versions. This Apple Support article explains how to enable automatic app updates. This is important since later versions of apps should not contain this malware. FireEye discovered large numbers of users (exact figures are provided in this FireEye blog post) still using older versions of their app which still contained the infected code).
  3. If you were using one of the apps removed by Apple from the App Store, uninstall those apps and switch to similar/alternative apps available within the App Store.
  4. Ensure that your Apple device is using the most recent version of iOS that is available for your device. If your device is too old to support iOS 9, this blog post may help to explain your options. Updating to most recent iOS will ensure that you are not affected by the original version of XcodeGhost. Moreover, iOS 9 and iOS 9.1 contain many fixes for other security vulnerabilities.

Thank you.

=======================
Original Post:
=======================
In recent days there has been detailed coverage of a new technique used to tamper with legitimate Apple iOS apps by adding extra code to those apps when they were being compiled (converted from human written source code into a form that a computer can use). That additional code called XcodeGhost was also found to contain a vulnerability that could allow remote access to the infected apps using a man-in-the-middle (MITM) (defined) attack as discussed in the ThreatPost article mentioned below.

In addition, a new technique used by malware authors to install a rootkit (see Aside below for a definition) on a user’s Android smartphone by having them download a popular app has also been discovered.

In order to provide advice and further information on how to protect yourself from these threats I wanted to respectfully give a shout out for the following new articles and blog posts:

I hope that you find these useful in further securing your Apple iOS or Google Android based smartphone from malware.

Thank you.

=======================
Aside:
What is a rootkit?
To provide a comprehensive definition of a rootkit I have chosen to quote from 2 well-known texts on the subject written by Reverend Bill Blunden in his book “The Rootkit Arsenal” (1st edition, Wordware Publishing 2009) and “Rootkits: Subverting the Windows Kernel” by Greg Hoglund and James Butler (Addison-Wesley, 2005). My thanks to them for providing excellent sources of information on this topic:

“A rootkit is a collection of tools (e.g. binaries, scripts, configuration files) that allow intruders to conceal their activity on a computer so that they can covertly monitor and control the system for an extended period of time by maintaining access to the root (defined) account.

While the above definition mentions a computer it still applies equally to smartphones since they run sophisticated operating systems, in this case Google Android.
=======================

Google Addresses Android Lockscreen Issue

Earlier this month Google released a security update to address 8 CVEs (defined) (2x critical severity, 4x high, 1x moderate, 1x low) within the Android smartphone operating system.

Among these issues was an Android lockscreen bypass. This issue involved entering a very large number of characters into the password prompt of the Android lockscreen when the Camera app is also open.

How Severe Is This Issue?
Google assigned it a moderate severity since it is an easy but tedious process to exploit this bug. In addition, this issue is only present if you are using a password to protect the lockscreen of your Android smartphone. More common methods of entering a PIN or using a pattern lock do not appear to be affected by this issue.

Moreover once exploited the attack will only have access to the apps on the home screen, they don’t obtain access to soft buttons or the keyboard. The security researcher who reported this issue to Google used Android Debug Bridge (adb) to access any data on the phone once it was in this partially unlocked state. Further discussion of this issue is provided in this Sophos blog post.

How Can I Protect Myself From This Issue?
Google released an over the air security update for its Nexus devices to fix this lockscreen (as well as other security issues). Please ensure that your Android device is running version 5.x (build LMY48M or later) to resolve this and the other security issues.

If your mobile carrier has not yet issued this update to your Android phone, please consider contacting them to check when this update will be issued to you and if possible find out how they plan on updating your phone each month as Google make updates available.

Thank you.

Further Android Vulnerabilities Disclosed

IBM X-Force have disclosed a serious security vulnerability in Google Android, the popular smartphone operating system. The flaw was disclosed in their research paper and presented at the USENIX Woot ’15 conference in Washington D.C.

The flaw known as the Android serialization vulnerability affected Android versions 4.3 (codenamed Jelly Bean) to 5.1 (Lollipop) and the upcoming version of Android currently codenamed M Preview 1. It affects approximately 55% of current Android phones in use. It allows the execution of code of an attacker’s choice but can only be exploited if malware was installed on the victim’s device.

How this does flaw work?
To demonstrate the issue, the security researchers replaced a genuine app with a fake one which would allow them to obtain any sensitive data that was entered into that app. The fake app was designed to target the privileged system_server process of Android in order to use it’s SELinux profile to allow the app to carry out privileged actions.

The researchers scanned a large number of Android app classes (see “Aside” at the end of this post for a definition), one was found that met of the following criteria:

  1. Is serializable;
  2. Contains a finalize method;
  3. Contains an attacker-controlled field.

This class, known as OpenSSLX509Certificate contained a controllable pointer (which points to code (tasks or actions) next to be carried out). Using this pointer the researchers were able to control which address in Androids memory to point at. They were then able to change the contents of this memory space to contain code of their choice.

Next, they bypassed ASLR (defined) by using the fact that all apps and some services including this fake app inherit the same memory layout (the very thing that ASLR is designed to prevent) since the fake app is also forked from the Zygote process (an app launcher process).

Moreover, the researchers managed to have their app execute (carry out their intended actions) as follows:

Overwriting the callback function pointer and then triggering a call to that pointer. This allows control of the program counter (PC)(The program counter is a register within your CPU which always holds the memory location of the next instruction to be executed).

Pointing the PC to a ROP (return oriented programming) gadget (both defined) and employs a stack pivoting technique. This ROP chain changes the memory space (mentioned above) to enable it to have the ability to run/execute code. The intended code is then placed within the memory space and executed.

Why Should This Issue Be Considered Important?
With the code of their choice placed in a location in memory that allows code to execute (carry out a set of actions); this allows the researchers to carry out any or all of the following actions:

  • Load arbitrary kernel modules in devices with kernel compiled with CONFIG_MODULES (kernel modules run with the highest level of privilege and can carry out any action they choose);
  • Steal data from any apps (e.g., by exploiting Android KeyChain app, which is allowed to run shell commands and access data);
  • Change SELinux policy rules;
  • Replace the code (APKs) of arbitrary apps.

How Can I Protect Myself From This Issue?
Sophos provides easy to use advice to protect yourself from this issue. In short, your Android smartphone should receive a patch to resolve this issue. The IBM researchers worked with Google to develop a fix for this issue.

Please note that the IBM researchers also found security issues in numerous Software Development its (SDKs) used to create Android apps. They also worked with the creators of such SDKs to develop fixes for the issues found. Further information on these flaws are provided in their detailed blog post.

My thanks to these researchers for providing an in-depth explanation of both the serialization and SDK issues.
=======================

Google Admin App Sandbox Bypass
The Android serialization issue was not the only issue recently disclosed by security researchers. The Google Admin app which allows users to access their Google for Work accounts was also found to contain an issue that allows attackers access to the files being used by the Google Admin app.

How this does flaw work?
Apologies but this explanation is as short as I can make it while explaining what’s happening as we go along:

The Google Admin app does not handle file URLs (examples of a URL would file://test.txt) correctly. The Google Admin app like other apps on Android is sandboxed (isolated within a protected container with no direct means of communicating with other apps) from other apps. To enable apps to communicate for useful and legitimate purposes Android uses inter process communication (IPC).

One such app interface is called setup_url. This can be used by another app to create an intent (a description of the action that an app wishes to perform, full definition here). Using this intent the attacker sets the URI (Uniform Resource Identifier) to a file on the device with the setup_url (mentioned above) to a file that the attacker can write to (has write access to).

A function (see Aside below for a definition) with the Google Admin app will then load this file (which the attacker can write to) with the same permissions the Google app possesses while the Google app renders (draws) the file/page in its WebView class (which enables it to display webpages, unsurprisingly!). The attacker can then add HTML code to this file and will then use an iframe (an HTML code tag used to embed one file within a currently in use HTML file) to load the file again.

The penultimate action for the attack is to delete the file that they can write to and replace it with a symbolic link (a means of representing a link to a file or a folder in a simpler way, an example is given at the end of this forum thread and a further explanation in this Sophos blog post) to a file of the same name within the Google App’s protected sandbox.

Finally, after one second has passed WebView will load the file within the sandbox. Since both the WebView and the WebView with the inserted iframe have the same URL (Uniform Resource Locator) the Same Origin Policy (a policy/rule that prevents code usually JavaScript from site A accessing private data belonging to site B) allows the WebView to query the contents of the WebView with the iframe (since the URLs are the same, the Same Origin Policy is not broken). Thus the HTML code added by the attacker can read the files within the iframe.

Why Should This Issue Be Considered Important?
A malicious app installed on your Android device could be able to read any data within any file contained in the normally inaccessible sandbox (protected storage area) of the Google Admin app.

How Can I Protect Myself From This Issue?
Please ensure that you have the latest version of the Google Admin app as described in this Sophos blog post since Google has addressed the above issue in this update.

=======================
Aside:
What is a class?

In the context of computer programming a class is set of variables (containers that store single values). The variables can be of different types e.g. integer and float (to represent floating point numbers e.g. 1.25). A class also contains one or more functions.

Functions allow a class to do something e.g. a class named Car would contains functions for accelerate, brake, park etc. A class allows a programmer to create an object which contains all of these variables and functions ready to use.
=======================

Google Android Stagefright Issues Patched

Update: 10th January 2016:
Further updates addressing newer issues within libstagefright have been made available. Please see this more recent blog post for details.

Thank you.

=======================
Update: 17th November 2015:
Further updates addressing newer Stagefright issues have been made available. Please see this more recent blog post for details.

Thank you.

=======================

Update: 5th October 2015:
A new set of security issues related to Stagefright has been disclosed. They are referred to as Stagefright 2.0. How to address these new issues is discussed in a more recent blog post.

Thank you.
=======================

Update: 13th August 2015:

According to this article, the patches that were intended to resolve the issues discussed in this post were incomplete. Further fixes will be made available in September. Further details are provided in the article linked to above. Thank you.
=======================

Update: 9th September 2015: The exploit code for the Android Stagefright issues as been released by the security researcher who discovered the issue. In addition, the researcher has worked with Google to create an app to check if an Android device is vulnerable. Moreover they are continuning to work with Google to add a check for this vulnerability to Android’s Compatibility Test Suite (CTS) to ensure all future Android devices ship with this issue fixed.

According to this article, the September update from Google to resolve the remaining means of exploiting the Stagefright has not yet been released but should be later this month.

=======================

=======================
Update: 15th September 2015: According to this article on Ars Technica, Google have begun to release the first batch of monthly security updates for Android for it’s Nexus devices. It will be interesting to see how quickly the OEM device makers and mobile carriers issue their updates. As this is the first time to release such updates it may take time for these update processes to be streamlined.

As mentioned below in the updated suggestions to protect yourself from the Android Stagefright issue, if you are using Mozilla Firefox for Android, please ensure that you are using the most recent version to ensure that you are protected from this issue. The steps to install updates for Firefox for Android are provided here.

Thank you.
=======================

Original Post:
In the middle of last week a series of security vulnerabilities were patched/updated in the Stagefright media playback service of Google Android smartphones (initial details of these issues became available a week before the updates).

There are 10 security issues in total assigned to 7 CVEs (CVE, defined). They consist of a buffer overflow and several integer overflow and underflow vulnerabilities (see Asides below definitions of these terms). These issues are present in all versions of Android since version 2.2 (codenamed Froyo) up to Android 5.1.1_r9 (codenamed Lollipop).

Why Should These Issues Be Considered Important?
While it is estimated that up to 950 million Android smartphones are affected by these security issues, more than 90 percent of them are protected by security mitigations (namely Address Space Layout Randomization (ASLR)) built into Android since version 4.0 (codenamed Ice Cream Sandwich). Additional improvements were made to the ASLR mitigation of Android in version 4.1 (Jelly Bean). However these mitigations make exploiting the Stagefright issues much more difficult but not impossible.

These security issues can be exploited by an attacker sending a specifically crafted Multimedia Messaging System (MMS) message (MMS, defined). To do this, the attacker only needs to know your phone number. MMS messages are processed automatically by most Android phones providing the attacker with the possibility of executing arbitrary shellcode (shellcode, defined) on your phone.

How Can I Protect Myself From These Issues?
Sophos provides practical advice on both mitigating the issue until a patch is available for your phone and how to obtain the patch for your phone. Further advice is available in Zimperium’s blog post and this CERT knowledge base article. Apologies that some of this information overlaps/is repeated but each link does contain useful information.

The good news that has occurred since more information was provided on these issues by the person who discovered them (Joshua Drake of Zimperium) last week in his BlackHat security lecture is that Google and Samsung have pledged to provide monthly security updates for their Nexus and Galaxy smartphones (respectively). LG have also pledged to do the same.

In addition, fixes to security issues will be made available to mobile carriers (mobile providers) sooner. This should result in a less complicated means of updating when future security vulnerabilities are discovered. The new monthly update process should keep Android smartphones much more secure in the future, this improvement is long overdue.

Update: 15th September 2015: In addition, if you are using Mozilla Firefox for Android, please ensure that you are using the most recent version to ensure that you are protected from this issue. The steps to install updates for Firefox for Android are provided here.

Thank you.

=======================
Aside:
What is an integer overflow?

When the value of an integer being used by a computing device becomes too large to be represented accurately e.g. on some systems the maximum value of an integer is 32767 (namely 2 ^ 15 -1). If a value higher than this is used to access a location in computer memory, that value may wrap around (begin counting from the beginning again resulting in a very small value or in a value less than its minimum value).

At best this will result in the program using that value crashing or getting caught in an infinite loop (performing the same action again and again without ending). At worst, an attack could use an integer overflow to overflow a buffer (a region in computer memory set aside (allocated) to hold a data or a value). This happens because the extra-large integer value flows over into parts of memory that it was not intended to.

This can result in an attack being able to run/execute code of their choice by overwriting the return pointer of the program (due to the overflow that has happened) with a value of the attackers choosing. That value is placed there by the overspill into adjacent memory segments. When an operation is completed, instead of the program returning (using the location the return pointer is referencing) to the place where it was originally asked (called from) the program will instead go to the place in memory where the attacker has stored malicious code (since the attacker supplied this location by inserting a value of their choice as mentioned above).

That code can then run with the same privileges of the program which suffered the overflow. The overwriting of the return pointer was one reason for Microsoft adding defences (namely guard stack cookies) part of the /GS mitigations to Windows Vista and all later versions of Windows. The other reason was being able to detect such buffer overflows and terminate the program which had suffered the overflow. By terminating/force closing the program the attack is immediately halted and the system remains secure. The /GS mitigation is explained in more depth here, here and here.

In explaining the integer overflow attack I have also defined the outcome of a buffer overflow attack.

Update: 25th August 2015: An individual definition of a buffer overflow attack is provided in a more recent blog post. Further mitigations for buffer overflow attacks are also discussed in that post.

=======================
Update: 17th September 2015:
A detailed definition of a stack overflow is provided in a more recent blog post. This similar type of overflow can be a useful addition to the explanations of overflows in this post. Thank you.
=======================

=======================
Aside 2:
What is an integer underflow?

Integer variables within computer programming languages such as C generally can store numbers in the range of -2,147,483,647 to 2,147,438,647. While the range of an unsigned integer ranges from 0 to 4,294,967,295.

If 2 numbers are subtracted from another and the result is less than -2,147,483,647 this will cause an integer underflow since the result cannot be represented correctly and thus will be incorrect when the computer accesses that result. This is because only a partial result will be shown since not enough digits are available to represent the full number. If the result is used to access a certain position in an array (called an index) the position accessed will result in an out of bounds error most likely crashing the program.

An array is a group of memory locations within a program allocated to store data of the same type e.g. integer, floating point etc. It is similar to have a filing cabinet with multiple folders inside. Arrays would store data in folders starting from 0 e.g. folder0, folder1, folder2 etc. The index mentioned above determines the number of the folder in this example being accessed. Arrays are usually accessed using loops within a program.

The above example is for signed integers however underflows can also occur with unsigned integers.

In a similar manner to that described for integer overflows, underflows can be used to trigger the execution (performing actions)/running of code of an attackers choice.
=======================