TL;DR; The Android Vulnerability Test Suite (Android VTS) was released on the Google Play Store just two weeks ago. Since, the NowSecure Research Team has been following the 1K+ reviews and implementing suggestions for vulnerable devices. We have actively been logging feedback and communicating with users both on the Google Play Store and Github. Many users have been particularly interested in information about individual vulnerabilities and steps they can take to improve security on their devices.
If VTS for Android is showing that you are vulnerable, this means that your device is running software with publicly known vulnerabilities and can be exploited. Each vulnerability affects your device in various ways. Based on feedback, we recognize the need to highlight more information about these specifics. As of version v.6, you should be able to find a brief description and impact summary for each vulnerability checked by VTS.
As a device owner, unfortunately, you have little control over the RsystemS software that makes it onto your device; you are at the mercy of the company that made the phone or the carrier that sold it to you. The following are suggestions and choices to consider after learning that your device is vulnerable:
- Ensure all device updates have been applied, if available
- For future purchases, consider devices that are better supported and receive more frequent updates like the Nexus line
- Install a third-party ROM like Cyanogenmod on your device (only recommended for tech-savy or power users)
- Continue to put pressure on your current original equipment manufacturer (OEM) to update / patch your device and hope that security updates get released in a timely manner
- Let phone manufacturers know that security is important to you. Vote with your money. Buy phones from the manufacturers that have a good track record of updating devices to fix these types of issues, such as Nexus devices.
Introduction
VTS brings awareness to the state of overall device security. Generally, this equates to pointing out the poor job that OEMs (and to a slightly lesser extent, carriers) do, including both the ability to patch bugs that affect Android and OEMUs lack of restraint in continually adding bloat/features. These features in particular have proven to be very buggy in the past and greatly increase the attack surface of devices. Now, IUd like to talk about why this is the case.
Google has little control over modifications / update frequency of OEM devices
Android is mostly an open source project. It primarily developed by Google and incorporates changes from the community. There are some pieces of Android which are not available to the general public: an internal bug tracker, and all of the development that happens between releases. By virtue of AndroidUs design and license, Google has little say in what people do with Android once the source is released. The OEMs (Samsung, HTC, Motorola, Sony, LG, etc..) take Android and make their own modifications to it before shipping it on their products. Google has a small bit of control over the modifications of Android through CTS (compatibility test suite). In order for the device to be allowed to use Google services and apps, it has to pass the CTS suite at time the device is made. CTS validates that very fundamental things have not changed, and in some cases even tests for some public vulnerabilities that the vulnerable device may be susceptible to. However, the issue with CTS is that it is only ran once for a given Android build for a device. There is no enforcement throughout the lifetime of the device. While this is fine for application compatibility, it falls short in making any kind of stride to keep devices secure throughout their lifetime.
OEM modifications are harmful
The Android Open Source Project (AOSP) is the collection of projects which make up Android. These projects are generally, with some exceptions, fairly mature. The level of difficulty of exploiting Android has risen significantly over the past few years. The attack surface has shrunk and many mitigations have been and are currently being put in place. Fine tuned access control policies have been developed to mitigate impact of various issues when they do happen. This work is reflected in the Nexus line of devices. OEMs have the ability to then take the AOSP and make modifications as they see fit, sometimes without regard for privacy and security; adding much bloatware in the form of both apps and integrated into the device itself. In the process, itUs not uncommon for OEMs to completely break the well-developed security mitigations such as SELinux. A great example of this is the attack vector used in remote code execution on the Galaxy S5. Although there are other vectors for exploitation, this particular one should have been broken by the SELinux policy that was in AOSP at the time but had not been adopted by Samsung. SamsungUs modifications have been disastrous:
- Remote code execution via added-on system app – Swiftkey
- Remote code execution via added-on hotspot functionality
- Misc. ownage by Project Zero
Samsung is not the only OEM to be picked on here, HTC and the like are just as much at fault. A summary of some OEM issues can be seen generally here. Other OEM screwups:
Poor device support
OEMs are not properly motivated to continue to support older devices with security patches. Continuing device support, even for security patches, costs OEMs resources that they can choose to expend elsewhere such as their latest flagship device(s). This works to their benefit as it provides incentives for users benefit because their device has not received proper software or security updates. Historically, manufacturers have been better about updating their flagship phones than about the budget lines. When shopping for a new phone, if itUs something you plan to use for years, then consider the manufacturerUs history of updates along with all the other features. Android device lifecycles are very short:
- Nexus Devices (Android flagships) lack in lifetime support compared to iOS counterparts
- Motorola poor device support overall
- Moto E supported for 219 days
In addition to very short device lifespans, the devices are updated very infrequently. When they are updated, it sometimes takes many months. Updates are generally applied by the OEM, including security updates, and can be improperly backported as well.
A Case Study
When recently testing VTS on a series of devices after some recent updates, we noticed some strange behavior on the Google Play Edition Moto G. The device is currently running 5.1.1 and while patched to most of the newer vulnerabilities we noticed that it was vulnerable to a critical issue CVE-2015-3825 allowing a local attacker to escalate privileges to system. The allure of purchasing a Google Play edition device, is that they generally have less bloatware and receive more frequent updates. Motorola presumably hand picked patches to backport to this device and missed this one.
Even in situations where the OEM attempts to stick closely to AOSP and has good intentions, the outcome is still often poor. OEMs could help mitigate this situation by developing completely in the open and allowing community contributions.
Power Users
Tech savvy users who donUt want to rely on the phoneUs manufacturer have some options available to them. Building AOSP, 3rd party roms, and xposed modules are a few of the choices that allow users to pick up the slack when OEMs and carriers fall short. A user with a phone whose last official update was Android 2.3 may compile and install a rom from AOSP which is based off a much more recent version of Android and contains many bug fixes. Cyanogenmod has done a particarly good job of supporting many devices and keeping up with backporting fixes. This project is a fork of Android Open Source Project (AOSP) that includes no bloatware and no breaking changes. If you do not own a Nexus device, this is probably your best alternative, if they support your device.
Attempts at triaging
Google recognized this problem and started the Android Update Alliance. This was an alliance containing some of the largest OEMs which banded together and promised a minimum device lifespan of 18 month. This alliance went quietly into the dark
Android security patch level
Recently Google introduced something new called Android security patch level. Not much information about this has been publicized by Google as of yet. However, it could be a sign that some security updates could be streamlined and deployed quicker. Historically, OEMs send their security patches and feature updates all in one to the carriers which can choose to do their own testing and deploy them at will. A focus on security only updates could help close the gap here and reduce the testing lag of both the OEM and the carrier, but at this point this is only speculation.
The Promise of Monthly Security Updates
After the slew of remote code execution bugs on Android (Stagefright, etc..), Google announced that they would update their Nexus devices monthly. Shortly thereafter, some OEMs started to follow suit: Samsung & LG. It is to be seen whether this will be impactful, as OEMsU only incentive to update devices for security seems to be avoiding public flogging. Some OEMs, such as HTC, have even publicly admitted that they arenUt committed to frequent security, treating them as a joke. These monthly updates, at least for Nexus device owners, are a step in the right direction. In addition, Google has started explicitly publishing monthly security bulletin updates. Moving forward, VTS will choose the most critical vulnerabilities (that are reasonable to check for) and include these checks shortly after the security bulletin is released.
