3.1 C
Saturday, November 18, 2017
Home Tags Full-disk encryption

Tag: Full-disk encryption

Experts point to stronger passwords, full-disk encryption, and multi-factor authentication as ways to stop data theft in the event a laptop is lost or stolen.
The next major version of OpenVPN, one of the most widely used virtual private networking technologies, will be audited by a well-known cryptography expert. The audit will be fully funded by Private Internet Access (PIA), a popular VPN service provider that uses OpenVPN for its business.

The company has contracted cryptography engineering expert Matthew Green, a professor at Johns Hopkins University in Baltimore, to carry out the evaluation with the goal of identifying any vulnerabilities in the code. Green has experience in auditing encryption software, being one of the founders of the Open Crypto Audit Project, which organized a detailed analysis of TrueCrypt, a popular open-source full-disk encryption application.

TrueCrypt has been abandoned by its original developers in 2014, but its code has since been forked and improved as part of other projects. Green will evaluate OpenVPN 2.4, which is currently the release candidate for the next major stable version.

For  now, he will look for vulnerabilities in the source code that’s available on GitHub, but he will compare his results with the final version when released in order to complete the audit. Any issues that are found will be shared with the OpenVPN developers and the results of the audit will only be made public after they have been patched, PIA’s Caleb Chen said in a blog post. “Instead of going for a crowdfunded approach, Private Internet Access has elected to fund the entirety of the OpenVPN 2.4 audit ourselves because of the integral nature of OpenVPN to both the privacy community as a whole and our own company,” Chen said. The OpenVPN software is cross-platform and can be used both in server or client modes.
It’s therefore used by end-users to connect to VPN servers and by companies to set up such servers.

The software is also integrated in commercial consumer and business products.
Android 7.0's crypto sauce is 'half-baked' and Google promises to make it better, soon Looking at the storage encryption Google has implemented in Android Nougat (7.0) through the metaphor of the glass that's either half full or half empty, cryptography expert Matthew Green sees Google's glass as all but drained. In a blog post last week, Green, assistant professor of computer science at Johns Hopkins University, said that optimists may feel that Android is moving in the right direction and that its "half-baked" implementation of file-based encryption is better than its implementation of full-disk encryption.

Then he noted that such people "probably also think clowns are nice." "On the other hand, you might notice that this is a pretty goddamn low standard," Green wrote. "In other words, in 2016 Android is still struggling to deploy encryption that achieves (lock screen) security that Apple figured out six years ago. And they’re not even getting it right." Green's post outlines the different approaches to encryption taken by Google and Apple.
Starting with Android KitKat (4.4) and continuing through Google Marshmallow (6.0), Google implemented full-disk encryption to protect Android devices. The drawback with this approach is that it's an all-or-nothing affair.

Android devices keep their cryptographic keys in memory, in order to ensure the device's applications can function while it's on.

But keeping crypto keys in memory is not very secure – sophisticated adversaries can extract keys from memory. "In principle, a clever implementation could evict sensitive cryptographic keys from RAM when the device locks, then re-derive them the next time the user logs in," explained Green. "Unfortunately, Android doesn't do this – for the very simple reason that Android users want their phones to actually work." Apple approached the problem from a different angle.
Starting with iOS 4, Apple implemented file-based encryption, protecting each file individually with its own unique key, Green said.

But it also allows individual keys to be encrypted with a class key tied to the user passcode and hardware-based secrets. These classes can be applied to accommodate several scenarios: Files can be encrypted until the device is on and unlocked. Files can be protected until the first user authentication, with keys remaining in memory thereafter. Files can be accessible after a reboot but prior to authentication. Files can be created with a key despite the absence of keys in memory, as one might desire when taking photos from smartphone lock screen. Android Nougat attempts to implement a system more like iOS through a new scheme called Direct Boot.
It allows the phone to access some data before the passcode has been entered.

But Android only provides two protection categories and these fail to cover all the desirable scenarios, according to Green. One problem with Google's approach, Green said, is that "there is no unambiguous way for Android to tell applications when the system has been re-locked." Without this, applications may start returning errors when the Android device gets locked. For Green, the problem is not so much Google's technology as that its lack of developer guidance prevents developers from creating apps that handle locked devices properly. Then there's the issue of the unfinished nature of Android's encryption code, which as Green points out, includes a TODO comment as a placeholder for the lines of C++ that, someday, will evict encryption keys from memory. //https://android.googlesource.com/platform/system/vold/+/master/Ext4Crypt.cpp bool e4crypt_lock_user_key(userid_t user_id) { if (e4crypt_is_native()) { // TODO: remove from kernel keyring } else if (e4crypt_is_emulated()) { // When in emulation mode, we just use chmod if (!emulated_lock(android::vold::BuildDataSystemCePath(user_id)) || !emulated_lock(android::vold::BuildDataMiscCePath(user_id)) || !emulated_lock(android::vold::BuildDataMediaCePath(nullptr, user_id)) || !emulated_lock(android::vold::BuildDataUserCePath(nullptr, user_id))) { LOG(ERROR) << "Failed to lock user " << user_id; return false; } } The bottom line is, these shortcomings make it a lot easier for anyone who seizes your Android phone, or can inject malware into it, to get your file decryption keys and extract your information.

Green noted: By treating encryption as a relatively low priority, Google is basically telling these people that they shouldn’t get the same protections as other users.

This may keep the FBI off Google’s backs, but in the long term it’s bad judgement on Google’s part. In an email to Green posted via Twitter, Google senior software engineer Paul Crowley chooses to see Google's encryption glass as half full, at least. "I was pleased to see you say that you consider Nougat's encryption to be an improvement over what came before it," he said. "That's very much how we see it." Then Crowley goes on to acknowledge that further work will be done to enhance Android security. ® Sponsored: Customer Identity and Access Management
Enlargereader comments 7 Share this story With fewer than 24 hours before polls open for the 2016 US presidential election, consider this your periodic reminder that e-voting machines expected to tally millions of votes are woefully antiquated and subject to fraud should hackers get physical access to them. A case in point is the Sequoia AVC Edge Mk1, a computerized voting machine that will be used in 13 states this year, including in swing states such as Arizona, Pennsylvania, and Wisconsin.

The so-called direct-recording electronic vote-counting system has long been known to be susceptible to relatively simple hacks that manipulate tallies and ballots. Researchers from security firm Cylance are driving that point home with demonstration hacks.

The first one causes one or more votes for one candidate to count as votes for that candidate's rival.

A second one alters the names as they appear on the electronic balloting screen.
Cylance discloses voting machine vulnerability. The hacks work by tampering with—or more precisely, reflashing—the PCMCIA card, a storage device in the voting machine that's similar to the tiny hard drive that's used by many digital cameras.

The fraud could be carried out by inserting a maliciously modified card inside a Sequoia AVC Edge machine, although the attackers would likely have to circumvent tamper-evident seals that are designed to flag such abuse.

The video above shows the hack being used to alter both the public and protective counters the machine uses to count and recount results to ensure tallies are valid.

The decade-old hack first came to public attention in 2007 in a research paper titled Source Code Review of the Sequoia Voting System. Stuffing the digital ballot box The Cylance demonstration came three weeks after researchers from competing security firm Symantec published a post with a similarly cautionary tone.
In it, researchers reported buying an unidentified DRE voting machine.

They, too, were able to hack a storage card used by the machines to effectively stuff the digital ballot box.
In the report, the Symantec researchers wrote: Voters entering polling stations that use electronic voting machines are handed a chip card that they use to cast their vote. Once someone has voted, they turn the card back in to the polling station volunteer and it gets re-used by the next voter. Just like credit cards, these cards are essentially a computer with its own RAM, CPU and operating system. Which means they can be exploited like any computing device. In examining the election process for vulnerabilities, we discovered that there’s an opportunity for a hacker to modify the code put on a voter’s chip card.

Anyone who knows how to program a chip card and purchases a simple $15 Raspberry Pi-like device could secretly reactivate their voter card while inside the privacy of a voting booth. We found a card reader that fits neatly into the palm of our hand and used it to reset our fake voter chip cards two different ways.
In one scenario, we reset the card to allow someone to vote multiple times using the same chip card. Our second method programmed the card to allow that card to cast multiple votes.
In both approaches, that attacker is stuffing the digital ballot box and casting doubt in the validity of the results from that polling station. Encryption absent on the voting machine hard drive We also discovered that there was no form of encryption on the internal hard drive of the voting machines we purchased, which were running an outdated operating system to display the ballots and record votes.

These types of hard drives are similar to those used in digital cameras.

The lack of full disk encryption on the internal hard drive (as well as the external cartridges) presents opportunities for hackers to reprogram and alter ballots. Potential hackers would also be unhindered by the voting machine’s lack of internet connectivity.
Some types of malware, such as Stuxnet, can take advantage of air-gapped networks and vector through physical access to a machine.

The lack of full-disk encryption on the DRE machine makes it easily exploitable, requiring only a simple device to reprogram the compact hard drive. Security experts have been quick to point out that hacking enough votes to alter an election is prohibitively hard to do.

As already noted, most hacks require physical access to machines that by law are required to be monitored by election officials. What's more, machines used in US elections are extremely diverse.

Taken together, these characteristics probably prevent hacks from scaling to the volumes that would be required to change the outcome of a national election. Still, the hacks might be used to alter a relatively small number of results in swing states, where outcomes have been known to be decided by fewer than a few hundred or a few thousand votes.

The hacks could also be used to sow widespread distrust in the official returns and undermine confidence in the legitimacy of the election. US intelligence officials recently accused the Russian government of hacking into the computer accounts of Democratic officials and leaking e-mails that could sway voters. Republican nominee Donald Trump has long warned of an election system that's "rigged" against him and has rebuffed calls that he pledge to accept the results should rival Hillary Clinton receive a majority of electoral college votes.

The lack of security in many of the nation's e-voting systems certainly doesn't inspire confidence.
In a keynote at the SecTor security conference, NSA whistleblower Edward Snowden detailed what he thinks is wrong with modern surveillance and what users can do to protect the internet. TORONTO—Edward Snowden appeared via a live web conference link at the SecTor conference here to deliver a keynote on the state of internet security and privacy today.
Snowden's comments covered a wide range of topics, including the use of back doors and what users can do to help protect their own privacy and that of the internet as a whole.Edward Snowden vaulted to global notoriety in 2013 after revealing classified details on the National Security Agency (NSA) and its mass surveillance programs.At SecTor, Snowden provided a grim estimation of the current state of IT security. "Offense has greatly surpassed defensive capabilities."Snowden noted that today's attackers aren't all that worried about being detected, as they're typically confident that they can get back into any given system.
In the past, intelligence services used to treat compromised systems as fragile resources, but today that's no longer the case, as it's easy for attackers to compromise new systems, he added. "Surveillance technology has outpaced democratic controls," Snowden said. A generation ago, surveillance was expensive and governments typically needed to spend huge sums of money and have large teams tasked with tracking any single individual, he said, adding that the situation has changed, and one person in front of a monitor can track a very large number of individuals."For the first time in human history, it is feasible for the government to track and have a complete record of all of our lives," Snowden warned. "This is not science fiction; it's happening now."Snowden commented that the lesson of the last few years, which he helped bring to light, is that government agencies doesn't always ask for permission when it comes to surveillance.
It happens that governments will deploy capabilities in secret, even if they know them to be unlawful.
Snowden told the SecTor audience that the issue of government surveillance isn't just a U.S. issue.
It's now known that the Canadian intelligence services routinely share information with the NSA.Fundamentally, Snowden is worried about a lack of proper oversight when it comes to government surveillance. Without proper oversight, Snowden said that the general public is forced to rely on the media and whistleblowers to reveal what is going on."If we only knew what the government wanted us to know, we'd know very little," Snowden said.While laws are important, at the end of the day, they are just letters on a page and can't actually enforce individuals' rights, Snowden remarked. He wants users and technology vendors to help take action to protect individual rights."We need collectively to make surveillance expensive again," Snowden said.What Snowden wants to see in both the United States and Canada is some form of proper oversight for surveillance activities.

There should be a case-by-case review of all surveillance requests after the fact to make sure that the surveillance was necessary, Snowden said.

This level of oversight would mean that if people at spy agencies break rules, they would be held accountable, he said.Snowden is also wary of different government spy agencies in Canada and in the United States sharing information on individuals, without any real necessity."Our information is being traded like baseball cards. We need some form of transparency and accountability."Snowden also commented on the ongoing public debate about enabling back doors in software that provide access for U.S. intelligence services.
In Snowden's view, inserting a back door is never a good idea. He believes back doors decrease rather than increase security."Everything is getting hacked all the time now," Snowden said.Having a backdoor makes hacking by attackers easier, whether they are affiliated with a nation-state or not, he said.Determining who is behind an attack is also very difficult in the modern world, Snowden said. "The only people that get caught are the least sophisticated and lazy adversary groups."Snowden wants technology vendors to remember to work for their customers and not for the government.

That means that companies should only hold data that is needed for their operational goals and nothing else, he said.Snowden suggests that end-users make use of two-factor authentication, full-disk encryption, password management systems as well as secure operating systems.

That said, Snowden added that it's important to help those that are working on protecting individual rights and privacy online."The average person doesn't have time to become a security expert, but what we can do is give $10 to a civil liberties organization that can contest illegal laws on our behalf," Snowden said.Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com.

Follow him on Twitter
Security researchers have completed the Open Source Technology Improvement Fund-backed audit of encryption platform VeraCrypt and found eight critical, three medium, and 15 low-severity vulnerabilities. The team behind the popular tool addressed the audit's findings in VeraCrypt 1.19. This is how security audits should work. OSTIF said VeraCrypt 1.9 is safe because most of the the flaws have been addressed. Some vulnerabilities were not addressed in this version, due to the "high complexity for the proposed fixes," but workarounds for those exist. "As long as you are following the documentation for known issues and using it as advised, I believe [VeraCrypt 1.9] is one of the best FDE [full-disk encryption] systems out there," said Derek Zimmer, OSTIF CEO and president, in an Ask-Me-Anything Q&A on Reddit. Zimmer is also a partner with virtual private network service provider VikingVPN. OSTIF hired Quarkslab senior security researcher Jean-Baptiste Bédrune and senior cryptographer Marion Videau to check the VeraCrypt codebase, focusing on version 1.18, and the DCS EFI Bootloader. The audit focused on new security features that were introduced into VeraCrypt after the April 2015 security audit of TrueCrypt. VeraCrypt is the fork of that now-abandoned encryption tool, and is backwards-compatible. Four problems in the bootloader -- keystrokes not being erased after authentication, sensitive data not correctly erased, memory corruption, and null/bad pointer references -- were found in the audit and fixed in version 1.19.  A low-severity boot password flaw, where the password length could be determined, was also addressed.  While the information leak itself is not critical, as the system needs to be booted and privileged access is required to read BIOS memory, the vulnerability needed to be fixed because an attacker knowing the length of the password would hasten the time needed for brute-force attacks, the audit said. VeraCrypt relied on compression functions to decompress the bootloader when the hard drive is encrypted, to create and check the recovery disks if the system is encrypted and uses UEFI, and during installation. The audit found that all the compression functions had issues. VeraCrypt was using XZip and XUnzip, which had known vulnerabilities and were out-of-date. "We strongly recommend to either rewrite this library and use an up-to-date version of zlib, or preferably, use another component to handle Zip files," the auditors said. VeraCrypt 1.19 replaced the vulnerable libraries with libzip, a modern and more secure zip library. UEFI is one of the most important -- and newest -- features added to VeraCrypt, so the auditors paid extra attention to this part of the code. All code specific to UEFI is in the VeraCrypt-DCS repository, and was "considered much less mature than the rest of the project" by VeraCrypt's lead developer, the researchers wrote in the audit report. "Some parts are incomplete, or not incomplete at all." In the audit summary OSTIF wrote that "VeraCrypt is much safer after this audit, and the fixes applied to the software mean that the world is safer when using this software."   As a result of the audit, VeraCrypt dumped GOST 28147-89 symmetric block cipher, originally added in VeraCrypt 1.17, due to errors in how it was implemented. GOST 28147-89 encryption was a Soviet-developed alternative to DES designed to strengthen the algorithm. All compression libraries were considered outdated or poorly written, the audit found. The implementation "fell short," Zimmer said in the Reddit AMA. In version 1.9, users can decrypt existing volumes that used the cipher but cannot create new instances. Users who used the GOST cipher that was removed as part of the audit should re-encrypt old partitions using the latest version. Users should also re-encrypt on all full-disk encryption systems since a number of issues with the bootloader have been fixed. Anyone who used pre-1.18 versions should re-encrypt partitions because of the bug related to the discovery of hidden partitions. VeraCrypt is a fork of TrueCrypt, which developers abruptly shut down in May 2014, hinting at unspecified security issues. There were concerns that the platform had a backdoor or some other flaw compromising the tool. The audit was necessary to assess the overall security of the platform. OSTIF said TrueCrypt 7.1a should no longer be considered safe because it is no longer under active maintenance and it is affected by the bootloader issues uncovered in the audit. However, the audit report also suggested that the weaknesses in TrueCrypt 7.1a do not affect the security of containers and non-system drives. It is easy to dismiss VeraCrypt as being unsafe because of the issues uncovered, but that ignores the entire value of having an audit. If the audit had uncovered issues and the team had refused to fix the issues, or were unresponsive to requests from the auditors, then that would give cause for concern. In this case, Quarkslab completed the audit in a month, and the maintainers fixed a significant number of the issues and documented in detail how to handle the other issues that hadn't been addressed. Yes, the auditors found some questionable decisions and mistakes that shouldn't have been made in the first place, but there were no problematic backdoors or any vulnerabilities that compromise the integrity of the full-disk encryption tool. The nature of open source development means the source code is available for anyone to examine. But, as has been repeatedly shown over the last few years, very few developers are actively looking for security flaws. This is why, despite the "many eyeballs" approach, Heartbleed and Shellshock and other critical vulnerabilities lingered in OpenSSL for years before being discovered. With an audit, professionals scrutinize every line of the open source software's source code to verify the integrity of the code, uncover security flaws and backdoors, and work with the project to fix as many problems as possible. The audit is typically expensive -- private search engine DuckDuckGo and virtual private network service Viking VPN were the primary donors to OSTIF for this audit -- which is why audits aren't more common. However, as many commercial products and other open source projects rely heavily on a handful of open source projects, audits are increasingly becoming important. With the VeraCrypt audit complete, the OSTIF is looking ahead to audits of OpenVPN 2.4. GnuPG, Off-the-Record, and OpenSSL are also on the roadmap. The Linux Foundation's Core Infrastructure Initiative had stated plans for a public audit of OpenSSL with NCC Group, but the status of that project is currently unclear. "I wish we could just hit every project that everyone likes, and my list would be enormous, but we have finite resources to work with and securing funding is the vast majority of our work right now," Zimmer wrote, noting that OSTIF is focusing on one "promising" project in each area of cryptography.
A new direct boot mode and a hardened media stack are just two of the enhancements in latest version of mobile operating system. With Google starting the rollout of its Android 7.0 Nougat to Nexus devices, the company this week reviewed some of the sec...
First set of security fixes issued for Nougat aka Android 7 It's a smaller-than-usual Android patch bundle from Google – just 47 patches for 57 flaws. These software bugs can be exploited by installed apps or malicious code smuggled in multimedia messages and files to gain total control of vulnerable phones, tablets, internet-connected fridges and other Android gadgets – allowing miscreants to snoop on victims and interfere with their lives. The first bundle of 19 patches addresses application and operating system-level vulnerabilities.

The second set of fixes covers driver-level holes.

The third set fixes two separate issues thought to be related to the full-disk encryption shortcomings from earlier in the year. All devices should get the first set, and some or all of the second and third batches depending on their chipsets and other hardware.
If you have a Nexus, you be offered the security updates to install very soon.
If not, you'll have to wait for your phone or tablet's manufacturer and mobile carrier to issue the update over-the-air, if at all. "Partners were notified about the issues described in the bulletin on August 5, 2016 or earlier," September's advisory states. "Where applicable, source code patches for these issues will be released to the Android Open Source Project (AOSP) repository in the next 48 hours. We will revise this bulletin with the AOSP links when they are available." The first tranche of patches mainly covers flaws found in Android's troubled Media Server, including one of the two critical fixes in the bundle and eight of the 11 high-level flaws.

The other critical patch is related, as it corrects a hole in LibUtils that would allow remote code execution. The privilege escalation bugs can be exploited by installed apps to take full control of the handheld or gadget.

The remote code execution flaws can be abused by things like specially crafted multimedia text messages and files to inject malicious code onto a device, which can use one of the escalation holes to potentially gain total control. Apps that use LibUtils to process file data can be potentially hijacked by maliciously crafted documents, and used to comprise the whole device using one of the available escalation bugs.

Also, Android's builtin debugger tool can be exploited by applications to commandeer a device. Patches for the programming blunders are available for Android 4.4.4 through to Android 7 aka Nougat. Issue CVE Severity Affects Nexus? Remote code execution vulnerability in LibUtils CVE-2016-3861 Critical Yes Remote code execution vulnerability in Media Server CVE-2016-3862 Critical Yes Remote code execution vulnerability in MediaMixer CVE-2016-3863 High Yes Elevation of privilege vulnerability in Media Server CVE-2016-3870, CVE-2016-3871, CVE-2016-3872 High Yes Elevation of privilege vulnerability in device boot CVE-2016-3875 High No* Elevation of privilege vulnerability in Settings CVE-2016-3876 High Yes Denial of service vulnerability in Media Server CVE-2016-3899, CVE-2016-3878, CVE-2016-3879, CVE-2016-3880, CVE-2016-3881 High Yes Elevation of privilege vulnerability in Telephony CVE-2016-3883 Moderate Yes Elevation of privilege vulnerability in Notification Manager Service CVE-2016-3884 Moderate Yes Elevation of privilege vulnerability in Debuggerd CVE-2016-3885 Moderate Yes Elevation of privilege vulnerability in System UI Tuner CVE-2016-3886 Moderate Yes Elevation of privilege vulnerability in Settings CVE-2016-3887 Moderate Yes Elevation of privilege vulnerability in SMS CVE-2016-3888 Moderate Yes Elevation of privilege vulnerability in Settings CVE-2016-3889 Moderate Yes Elevation of privilege vulnerability in Java Debug Wire Protocol CVE-2016-3890 Moderate No* Information disclosure vulnerability in Media Server CVE-2016-3895 Moderate Yes Information disclosure vulnerability in AOSP Mail CVE-2016-3896 Moderate No* Information disclosure vulnerability in Wi-Fi CVE-2016-3897 Moderate No* Denial of service vulnerability in Telephony CVE-2016-3898 Moderate Yes The bulk of the moderate-severity patches in this first bundle deal with privilege escalation problems in the Android code.

These are usually pretty harmless, unless combined with more serious flaws for advanced hacking attacks. The second bundle, covering Android up to September 5, is the largest of the trio, with 26 patches for 30 flaws.

Four of these are critical – all covering elevation of privilege attacks on the kernel – and deal with flaws in the networking and netfilter subsystems, as well as the USB and sound-handling Android zones. Issue CVE Severity Affects Nexus? Elevation of privilege vulnerability in kernel security subsystem CVE-2014-9529, CVE-2016-4470 Critical Yes Elevation of privilege vulnerability in kernel networking subsystem CVE-2013-7446 Critical Yes Elevation of privilege vulnerability in kernel netfilter subsystem CVE-2016-3134 Critical Yes Elevation of privilege vulnerability in kernel USB driver CVE-2016-3951 Critical Yes Elevation of privilege vulnerability in kernel sound subsystem CVE-2014-4655 High Yes Elevation of privilege vulnerability in kernel ASN.1 decoder CVE-2016-2053 High Yes Elevation of privilege vulnerability in Qualcomm radio interface layer CVE-2016-3864 High Yes Elevation of privilege vulnerability in Qualcomm subsystem driver CVE-2016-3858 High Yes Elevation of privilege vulnerability in kernel networking driver CVE-2016-4805 High Yes Elevation of privilege vulnerability in Synaptics touchscreen driver CVE-2016-3865 High Yes Elevation of privilege vulnerability in Qualcomm camera driver CVE-2016-3859 High Yes Elevation of privilege vulnerability in Qualcomm sound driver CVE-2016-3866 High Yes Elevation of privilege vulnerability in Qualcomm IPA driver CVE-2016-3867 High Yes Elevation of privilege vulnerability in Qualcomm power driver CVE-2016-3868 High Yes Elevation of privilege vulnerability in Broadcom Wi-Fi driver CVE-2016-3869 High Yes Elevation of privilege vulnerability in kernel eCryptfs filesystem CVE-2016-1583 High Yes Elevation of privilege vulnerability in NVIDIA kernel CVE-2016-3873 High Yes Elevation of privilege vulnerability in Qualcomm Wi-Fi driver CVE-2016-3874 High Yes Denial of service vulnerability in kernel networking subsystem CVE-2015-1465, CVE-2015-5364 High Yes Denial of service vulnerability in kernel ext4 filesystem CVE-2015-8839 High Yes Information disclosure vulnerability in Qualcomm SPMI driver CVE-2016-3892 Moderate Yes Information disclosure vulnerability in Qualcomm sound codec CVE-2016-3893 Moderate Yes Information disclosure vulnerability in Qualcomm DMA component CVE-2016-3894 Moderate Yes Information disclosure vulnerability in kernel networking subsystem CVE-2016-4998 Moderate Yes Denial of service vulnerability in kernel networking subsystem CVE-2015-2922 Moderate Yes Vulnerabilities in Qualcomm components CVE-2016-2469 High No Of the high-priority fixes, the vast majority are also privilege escalation problems with a variety of drivers.

As with previous months, Qualcomm's kit gets a lot of patches, although Nvidia and Synaptics get one apiece. The third patch bundle contains just two patches – one critical and one high priority – but both for the Nexus phone range.

The critical patch is in kernel memory system and would allow a malicious app downloaded onto the handset to manipulate the memory and be so persistent you'd have to wipe the handset back to factory settings. Issue CVE Severity Affects Nexus? Elevation of privilege vulnerability in kernel shared memory subsystem CVE-2016-5340 Critical Yes Elevation of privilege vulnerability in Qualcomm networking component CVE-2016-2059 High Yes The second flaw, rated high, fixes a similar issue with the Qualcomm networking component, which would allow code execution in the kernel. ®
Guardian Projectreader comments 40 Share this story A startup on a shoestring budget is working to clean up the Android security mess, and has even demonstrated results where other "secure" Android phones have failed, raising questions about Google's willingness to address the widespread vulnerabilities that exist in the world's most popular mobile operating system. "Copperhead is probably the most exciting thing happening in the world of Android security today," Chris Soghoian, principal technologist with the Speech, Privacy, and Technology Project at the American Civil Liberties Union, tells Ars. "But the enigma with Copperhead is why do they even exist? Why is it that a company as large as Google and with as much money as Google and with such a respected security team—why is it there's anything left for Copperhead to do?" Copperhead OS, a two-man team based in Toronto, ships a hardened version of Android that aims to integrate Grsecurity and PaX into their distribution.

Their OS also includes numerous security enhancements, including a port of OpenBSD’s malloc implementation, compiler hardening, enhanced SELinux policies, and function pointer protection in libc. Unfortunately for security nuts, Copperhead currently only supports Nexus devices. Google's Android security team have accepted many of Copperhead's patches into their upstream Android Open Source Project (AOSP) code base.

But a majority of Copperhead's security enhancements are not likely ever to reach beyond the its small but growing user base, because of performance trade-offs or compatibility issues. Dan Guido, CEO of Trail of Bits, has also puzzled over the vulnerability gap between the stock Android OS and Copperhead, and points out that the same could not be said for Apple's iOS. "If I had to imagine a world where there's a Copperhead for iOS, I don't even know what I'd change," he tells Ars. "The Apple team almost always picked the more secure path to go and has found a way to overcome all these performance and user experience issues." A billion people around the world rely on Android to secure their digital lives.

This number is only going to grow. How did we get here, and can Copperhead—or even Google—put out the garbage fire? Enlarge / A general outline of Copperhead's main features. A deal with the devil Google did a deal with the devil for market share, says Soghoian, who has described the current parlous state of Android security as a human rights issue.

By giving Original Equipment Manufacturers (OEMs) and wireless carriers control over the end-user experience, Google allowed handset manufacturers to find ways to differentiate their products, and wireless carriers to disable features they thought would threaten their business model. As a result, Google's power over OEMs—such as Samsung or Motorola, who manufacture and sell Android handsets—consists solely of the Android license and access to the Google Play Store.

The AOSP code base is licensed with Apache 2.0, and the kernel uses GPL2, which means there's nothing stopping OEMs from deploying stock Android under a different name.

But doing so would also mean losing access to the Play Store.

This gives Google significant leverage over OEMs, but by no means absolute control—a competitor willing to forgo the Android trademark and offer customers access to their own app store, as Amazon has done, can walk away from the negotiating table with little to no consequence. But Soghoian thinks Google isn't trying very hard.

The company could, he points out, demand that OEMs implement default full-disk encryption as part of the Android and Play Service licence terms.

The company currently requires FDE when the hardware supports it, but extending that requirement to lower-end Android manufacturers might scare off a non-trivial fraction of OEMs—and that would hurt Google's bottom line as an advertising company. "The important thing to remember," he says, "is that if Google goes nuclear and cuts an OEM from the Google Play store, and Gmail, and Google Maps, and YouTube, Google isn't just hurting that OEM and its customers, it's also hurting itself." "Every phone that doesn't have YouTube and Google Mail and search is a phone that isn't making money for Google," he adds. Copperhead, for their part, are not in the business of surveilling users in order to display targeted advertising and so are free to optimise Android for security.

Their first challenge was to find a handset to support that offered regular security updates—no small ask. Just the Nexus, thanks Most OEMs, for instance Motorola, do not ship the monthly security updates available from the AOSP.

The business model for handset manufacturers ends with the sale to a consumer—at which point there are no financial incentives to maintain the devices for the next three years or so. Copperhead chooses to focus on optimising security for what they believe are the most secure handsets currently available: the Nexus devices whose software, if not hardware, Google controls directly, and which receive prompt monthly security updates. "What we're doing is starting with the Nexus; a pretty good starting point," Copperhead's Daniel Micay explains. "And we're significantly improving the security of the operating system. We're making a lot of under-the-hood changes and exploit mitigation to make it harder to exploit the vulnerabilities that are there." Micay's goal is to port the Grsecurity and PaX patches to the Android Linux kernel, which would dramatically improve the security of all Android handsets, but this goal has been stymied by hardware woes—some of which not even Google appears capable of resolving, at least not on its own. Grsecurity for Android Grsecurity and its subset PaX harden the Linux kernel by making whole classes of vulnerabilities difficult, if not impossible, to exploit. Micay got his start as the Arch Linux maintainer of the Grsecurity and PaX patches for that distribution, and embraces the same security vision as Brad Spengler, who founded the Grsecurity project, and who has famously clashed with Linus Torvalds over the years for the latter's reluctance to ship a more secure kernel. But Copperhead's efforts to implement the Grsecurity patches for Android ran into a brick wall: Nexus devices, and indeed all newer mid- to high-end handsets, use the ARM64 architecture. While parts of Grsecurity have been ported to ARM32, little work has been done on ARM64, Micay says, leaving only a small subset of non-architecture-specific code for him to deploy. Porting Grsecurity to ARM64 is not a trivial undertaking—Micay estimates months of work for an experienced engineer, and Spengler and his team are not inclined to help without getting paid. "Work on Grsecurity is still done in our free time," Spengler says. "We don't have any personal need for ARM64 support, so it's not a priority for us in our limited time.
I do have a development board on order, however." "We would have to research how KERNEXEC/UDEREF functionality could be implemented best on ARM64," he adds. "Given our experience with that research and implementation on ARM, I'm not inclined to do more free work for the full-time funded upstream or multi-billion dollar corporations to rip off." Given the dramatic security benefits porting Grsecurity to Android would bring, and the relatively low cost of such work, Soghoian wonders why no one is paying Spengler and Micay to do so. Is Android critical infrastructure? "In an ideal world, the US Department of Homeland Security would write a check to Spengler for $5 million and keep him busy," Soghoian says, pointing to the Core Infrastructure Initiative (CII), founded after Heartbleed to take better care of critical open source security software like OpenSSL. Because the Grsecurity project has the potential to positively benefit every Linux user on the planet—including servers, desktops, and more than a billion Android users—Soghoian argues that the project is the kind of thing the CII should be funding. "The White House announced they were going to put more money into the open source community a few months ago," he says. "It's a totally realistic scenario." Soghoian also criticises Google for failing to step up to the plate. "Google could pay for the development of Grsecurity using the money found between the cushions of their sofa," he insists. "This is not a big-ticket item in the grand scheme of Google's budget." But even if ARM64 support were immediately available for the Android kernel, it would still be a year or two before Copperhead—or even Google—could deploy those patched kernels. Kernel freeze Linux device drivers have been the operating system's Achilles heel since day one, and the Android platform is no exception.

Android phones ship with kernels frozen to ensure driver compatibility—which usually means that a new Android device comes with a kernel that's already a year or two old. "It's like if you have a printer and the last printer driver made was for Windows 95, you can never upgrade your computer to a newer version," Soghoian explains. "Android is bigger than just Google, and when Google's partners drag their feet it undermines the security of the entire ecosystem." As an Android device ages, the kernel may get backported security patches, depending on the OEM’s willingness to push updates, but the handset will miss out on the latest security advances, since upgrading the kernel would break hardware compatibility with the drivers. This ties Copperhead's hands.

Given limited resources, Micay says he's focusing on implementing new security improvements to Android, rather than backporting a limited, non-architecture-specific subset of Grsecurity to the older kernels currently running on Nexus devices. "Nexus devices are stuck on Linux kernel 3.10, which is not supported by PaX and Grsecurity,” he says. “I've chosen to focus on long-term progress so there's no value in porting stuff back to 3.10 since future devices will use different newer kernels." Google is playing up the security enhancements in Android 7.0, dubbed “Nougat”, which will ship later this year. How significant is the new release in terms of security? Enlarge “N” to the rescue? The Android security team did not respond to requests for comment over the last couple of weeks. On July 27, they published a blog post touting the integration of a subset of Grsecurity patches in Android N. Micay dismisses this announcement, saying that Google has in reality implemented less than one percent of Grsecurity into Android. "Android N is making more progress on kernel exploit mitigations than past releases of Android, but it's basic stuff and doesn't change the fact that the kernel is a very soft target," he says. “They're taking baby steps forward for the kernel's security.
Security elsewhere in Android is moving much faster though (the mediaserver hardening, multiprocess WebView, SELinux policies, hidepid=2, etc.)” Google finally responded to our request for comment on Monday, August 1.
In a brief statement, Adrian Ludwig, Google's director of Android security, wrote: “Copperhead has been a valuable contributor to Android Open Source project. We appreciate their contributions, and hope that they continue to work on research and development that improves security of the entire Android ecosystem.” Can Copperhead succeed where others failed? The marketplace is littered with dead and dying Android security startups.
Silent Circle's Blackphone is going nowhere fast, and nor is backdoor-loving Blackberry’s Priv.

CyanogenMod OS, although by no means optimised for security, has also found competing with stock Android a far-from-profitable venture. Absent an unexpected cheque in the mail from Google or the US DHS, how will Copperhead fund its cutting-edge work on securing Android? Enlarge / The Blackphone 2, another attempt at improving mobile phone security. The startup currently sells Nexus devices with Copperhead OS preinstalled, and Micay says they are in talks with a number of potential enterprise clients and resellers who would benefit from hardened Android devices customised to suit their users. "There are no doubt many organisations globally who want full control over the software stacks on their devices, who do not want the cloud services that are bound to the dominant mobile device operating systems, yet they want modern devices," says David Mirza Ahmad of Subgraph, a Copperhead-like effort to secure desktop Linux. "Copperhead could be the answer." Copperhead ships with F-Droid installed by default, but without Google Play. Nexus owners comfortable with re-flashing their own devices can, of course, download Copperhead OS and install it themselves.

The company also accepts donations and offers a Patreon subscription. For his part, Micay is in this for the long haul, whether Copperhead is financially successful or not: "Even if I have to get a full-time job I'll still going to be doing this because it matters." J.M. Porup is a freelance cybersecurity reporter who lives in Toronto. When he dies his epitaph will simply read "assume breach." You can find him on Twitter at @toholdaquill. This post originated on Ars Technica UK
Or buy something that doesn't use a Qualcomm Snapdragon Another month means another double bundle of security vulnerability patches for Android. Google is sticking to the twin-release pattern it used last month: the first batch addresses flaws in Android's system-level software that everyone should install, and the second squashes bugs in hardware drivers and kernel-level code that not everyone needs. The first patch set closes holes in Android 4.4.4 to the current build. Owners of Nexus gear will get these patches over-the-air very soon; everyone else will have to wait for their gadget makers and cellphone networks to issue them – which might be forever, leaving them forever vulnerable. These holes include programming blunders in Mediaserver that can be exploited by a specially crafted MMS or an in-browser media file to potentially execute malicious code on a device.

Getting a bad text or visiting an evil webpage could be enough to slip spyware onto your device, provided it is able to defeat ASLR and other defense mechanisms. Mediaserver has other bugs, including four elevation-of-privileges holes allowing installed apps to gain more control of a device than they should, and code cockups that can crash a handheld. The remaining patches address information leakages in the Wi-Fi, camera, SurfaceFlinger and Mediaserver code, and OpenSSL, all of which can be abused by installed apps to "access sensitive data without permission." The full list is here: Issue CVE Severity Affects Nexus? Remote code execution vulnerability in Mediaserver CVE-2016-3819, CVE-2016-3820, CVE-2016-3821 Critical Yes Remote code execution vulnerability in libjhead CVE-2016-3822 High Yes Elevation of privilege vulnerability in Mediaserver CVE-2016-3823, CVE-2016-3824, CVE-2016-3825, CVE-2016-3826 High Yes Denial of service vulnerability in Mediaserver CVE-2016-3827, CVE-2016-3828, CVE-2016-3829, CVE-2016-3830 High Yes Denial of service vulnerability in system clock CVE-2016-3831 High Yes Elevation of privilege vulnerability in framework APIs CVE-2016-3832 Moderate Yes Elevation of privilege vulnerability in Shell CVE-2016-3833 Moderate Yes Information disclosure vulnerability in OpenSSL CVE-2016-2842 Moderate Yes Information disclosure vulnerability in camera APIs CVE-2016-3834 Moderate Yes Information disclosure vulnerability in Mediaserver CVE-2016-3835 Moderate Yes Information disclosure vulnerability in SurfaceFlinger CVE-2016-3836 Moderate Yes Information disclosure vulnerability in Wi-Fi CVE-2016-3837 Moderate Yes Denial of service vulnerability in system UI CVE-2016-3838 Moderate Yes Denial of service vulnerability in Bluetooth CVE-2016-3839 Moderate Yes The second patch bundle contains fixes for driver-level code, and whether or not you need each of them depends on your hardware: if you have a chipset that introduces one of these vulnerabilities, you'll need to install a fix. Nexus owners will get these automatically as necessary; other phone and tablet manufacturers may roll them out as and when they feel ready.

That could be never in some cases. The bundle predominantly fixes problems with Qualcomm's driver software – Qualy being the dominant Android system-on-chip designer, and its Snapdragon SoCs are used pretty much everywhere.

These Qualcomm bugs are definitely ones to watch as these kinds of low-level flaws were used to blow apart Android's full-disk encryption system last month. The patches includes fixes for Qualcomm's bootloader, and Qualcomm drivers for cameras, networking, sound, and video hardware.

A malicious app on a Qualcomm-powered phone or tablet could exploit these to gain kernel-level access – completely hijacking the device, in other words.

An app could use these holes to root a Nexus 5, 5X, 6, 6P and 7 so badly it would need a complete factory reset to undo the damage. There are other bugs fixed in this batch because they can be exploited by malicious applications on Qualcomm-powered devices to access "sensitive data without explicit user permission." The full list is below: Issue CVE Severity Affects Nexus? Remote code execution vulnerability in Qualcomm Wi‑Fi driver CVE-2014-9902 Critical Yes Remote code execution vulnerability in Conscrypt CVE-2016-3840 Critical Yes Elevation of privilege vulnerability in Qualcomm components CVE-2014-9863, CVE-2014-9864, CVE-2014-9865, CVE-2014-9866, CVE-2014-9867, CVE-2014-9868, CVE-2014-9869, CVE-2014-9870, CVE-2014-9871, CVE-2014-9872, CVE-2014-9873, CVE-2014-9874, CVE-2014-9875, CVE-2014-9876, CVE-2014-9877, CVE-2014-9878, CVE-2014-9879, CVE-2014-9880, CVE-2014-9881, CVE-2014-9882, CVE-2014-9883, CVE-2014-9884, CVE-2014-9885, CVE-2014-9886, CVE-2014-9887, CVE-2014-9888, CVE-2014-9889, CVE-2014-9890, CVE-2014-9891, CVE-2015-8937, CVE-2015-8938, CVE-2015-8939, CVE-2015-8940, CVE-2015-8941, CVE-2015-8942, CVE-2015-8943 Critical Yes Elevation of privilege vulnerability in kernel networking component CVE-2015-2686, CVE-2016-3841 Critical Yes Elevation of privilege vulnerability in Qualcomm GPU driver CVE-2016-2504, CVE-2016-3842 Critical Yes Elevation of privilege vulnerability in Qualcomm performance component CVE-2016-3843 Critical Yes Elevation of privilege vulnerability in kernel CVE-2016-3857 Critical Yes Elevation of privilege vulnerability in kernel memory system CVE-2015-1593, CVE-2016-3672 High Yes Elevation of privilege vulnerability in kernel sound component CVE-2016-2544, CVE-2016-2546, CVE-2014-9904 High Yes Elevation of privilege vulnerability in kernel file system CVE-2012-6701 High Yes Elevation of privilege vulnerability in Mediaserver CVE-2016-3844 High Yes Elevation of privilege vulnerability in kernel video driver CVE-2016-3845 High Yes Elevation of privilege vulnerability in Serial Peripheral Interface driver CVE-2016-3846 High Yes Elevation of privilege vulnerability in NVIDIA media driver CVE-2016-3847, CVE-2016-3848 High Yes Elevation of privilege vulnerability in ION driver CVE-2016-3849 High Yes Elevation of privilege vulnerability in Qualcomm bootloader CVE-2016-3850 High Yes Elevation of privilege vulnerability in kernel performance subsystem CVE-2016-3843 High Yes Elevation of privilege vulnerability in LG Electronics bootloader CVE-2016-3851 High Yes Information disclosure vulnerability in Qualcomm components CVE-2014-9892, CVE-2014-9893, CVE-2014-9894, CVE-2014-9895, CVE-2014-9896, CVE-2014-9897, CVE-2014-9898, CVE-2014-9899, CVE-2014-9900, CVE-2015-8944 High Yes Information disclosure vulnerability in kernel scheduler CVE-2014-9903 High Yes Information disclosure vulnerability in MediaTek Wi-Fi driver CVE-2016-3852 High Yes Information disclosure vulnerability in USB driver CVE-2016-4482 High Yes Denial of service vulnerability in Qualcomm components CVE-2014-9901 High Yes Elevation of privilege vulnerability in Google Play services CVE-2016-3853 Moderate Yes Elevation of privilege vulnerability in Framework APIs CVE-2016-2497 Moderate Yes Information disclosure vulnerability in kernel networking component CVE-2016-4578 Moderate Yes Information disclosure vulnerability in kernel sound component CVE-2016-4569, CVE-2016-4578 Moderate Yes Vulnerabilities in Qualcomm components CVE-2016-3854, CVE-2016-3855, CVE-2016-3856 High No Based on past experience, Nexus users are going to get both sets of patches within the next seven days. Other Android users may have to wait an awful lot longer – during which time, they'll be potentially vulnerable to attack. ® PS: Yeah, yeah, BlackBerry's Priv and DETK50 Androids get patches at the same time as Nexuses. We know. Sponsored: Global DDoS threat landscape report
What a coincidence Google has released two bundles of Android security patches this month: a smaller one to handle bugs in the operating system, and a larger package that tackles a raft of driver-level issues, particularly with Qualcomm's hardware. The first tranche of patches includes eight critical, 11 high severity, and nine fixes that are considered moderate.

All but one of the critical patches are for Android's soon-to-be redesigned Mediaserver, along with seven high-severity fixes and three moderates. As ever, people have found new ways to corrupt and hijack Mediaserver using booby-trapped video files and multimedia messages. Opening a malicious vid could lead to full remote code execution on Android devices from version 4.4.4 up to the most recent build. The other critical fix covers a flaw in OpenSSL and Google's stripped-down software fork BoringSSL.

These libraries also suffer from memory corruption bugs that can be potentially exploited to execute code on vulnerable devices. Other issues of high importance in the update include a fix on the way Android handles Bluetooth communications that would allow an attacker to inject and run code on a nearby device when performing an initial pairing with a new person.

Below is the full flaw list. Issue CVE Severity Affects Nexus? Remote code execution vulnerability in Mediaserver CVE-2016-2506, CVE-2016-2505, CVE-2016-2507, CVE-2016-2508, CVE-2016-3741, CVE-2016-3742, CVE-2016-3743 Critical Yes Remote code execution vulnerability in OpenSSL & BoringSSL CVE-2016-2108 Critical Yes Remote code execution vulnerability in Bluetooth CVE-2016-3744 High Yes Elevation of privilege vulnerability in libpng CVE-2016-3751 High Yes Elevation of privilege vulnerability in Mediaserver CVE-2016-3745, CVE-2016-3746, CVE-2016-3747 High Yes Elevation of privilege vulnerability in sockets CVE-2016-3748 High Yes Elevation of privilege vulnerability in LockSettingsService CVE-2016-3749 High Yes Elevation of privilege vulnerability in Framework APIs CVE-2016-3750 High Yes Elevation of privilege vulnerability in ChooserTarget service CVE-2016-3752 High Yes Information disclosure vulnerability in Mediaserver CVE-2016-3753 High No* Information disclosure vulnerability in OpenSSL CVE-2016-2107 High No* Denial of service vulnerability in Mediaserver CVE-2016-3754, CVE-2016-3755, CVE-2016-3756 High Yes Denial of service vulnerability in libc CVE-2016-3818 High No* Elevation of privilege vulnerability in lsof CVE-2016-3757 Moderate Yes Elevation of privilege vulnerability in DexClassLoader CVE-2016-3758 Moderate Yes Elevation of privilege vulnerability in Framework APIs CVE-2016-3759 Moderate Yes Elevation of privilege vulnerability in Bluetooth CVE-2016-3760 Moderate Yes Elevation of privilege vulnerability in NFC CVE-2016-3761 Moderate Yes Elevation of privilege vulnerability in sockets CVE-2016-3762 Moderate Yes Information disclosure vulnerability in Proxy Auto-Config CVE-2016-3763 Moderate Yes Information disclosure vulnerability in Mediaserver CVE-2016-3764, CVE-2016-3765 Moderate Yes Denial of service vulnerability in Mediaserver CVE-2016-3766 Moderate Yes But wait, there's more So far, so Google.

The patch bundle is in line with other monthly patching packages from the Chocolate Factory.
If you have a Google Nexus device, you'll get your hands on these fixes soon enough over the air automatically.
If not, you may well have to wait a while for your device manufacturer and mobile carrier to push these updates to you – if they ever appear. Meanwhile, Google is issuing a second string of patches that aren't going on general release: they'll be pushed out to Nexus owners and to hardware manufacturers who are expected to then pass on the updates to their customers. This second set is a much larger tranche of code, including 12 critical fixes, 54 rated high severity, and nine moderates.

Google said the second patch bundle will "provide Android partners with the flexibility to move more quickly to fix a subset of vulnerabilities that are similar across all Android devices." What could this subset of vulnerabilities be? The list of fixes contains some interesting hints. Last week, security researcher Gal Beniamini found a way to defeat Android's full-disk encryption system using blunders in Qualcomm's KeyMaster cryptography program.

The design flaws can be potentially exploited by someone who has seized your device to unlock and decrypt your encrypted file system with brute force. Google and Qualcomm said the problem was fixed in patches issued in January and May, and Mountain View paid Beniamini a bug bounty for his find.

But the researcher pointed out that other flaws hiding within Android, particularly elevation of privilege bugs, could be found and exploited to break the encryption system again. So it's interesting that this secondary bundle includes fixes for 40 flaws with Qualcomm components – more than half of the total, and pretty much all of them are escalation-of-privilege holes.
If you were emitting a set of fixes to shore up devices against KeyMaster-based attacks, it would probably look a lot like this one. The first two critical patches on the list are for the Qualcomm GPU drivers in Nexus 5X, 6, and 6P, to fix an elevation of privilege vulnerability that would allow an attacker to "execute arbitrary code within the context of the kernel." There are another 36 Qualcomm high- and moderate-severity flaw fixes included in the release. All Nexus devices get a critical patch for an elevation of privilege vulnerability in the Android kernel file system that would have the same effect. Nexus 5 and 7 devices also get critical fixes for security vulnerabilities affecting Qualcomm components including the bootloader, camera, character, networking, sound, and video drivers. There are also six critical patches for the Android One operating system, used by its basic device range.

They fix flaws in the MediaTek Wi-Fi driver and other parts of the supplier's kit that would compromise the kernel and lead to the device having to be wiped to recover. The full list is below. ® Issue CVE Severity Affects Nexus? Elevation of privilege vulnerability in Qualcomm GPU driver (Device specific) CVE-2016-2503, CVE-2016-2067 Critical Yes Elevation of privilege vulnerability in MediaTek Wi-Fi driver (Device specific) CVE-2016-3767 Critical Yes Elevation of privilege vulnerability in Qualcomm performance component (Device specific) CVE-2016-3768 Critical Yes Elevation of privilege vulnerability in NVIDIA video driver (Device specific) CVE-2016-3769 Critical Yes Elevation of privilege vulnerability in MediaTek drivers (Device specific) CVE-2016-3770, CVE-2016-3771, CVE-2016-3772, CVE-2016-3773, CVE-2016-3774 Critical Yes Elevation of privilege vulnerability in kernel file system (Device specific) CVE-2016-3775 Critical Yes Elevation of privilege vulnerability in USB driver (Device specific) CVE-2015-8816 Critical Yes Elevation of privilege vulnerability in Qualcomm components (Device specific) CVE-2014-9794, CVE-2014-9795, CVE-2015-8892, CVE-2013-7457, CVE-2014-9781, CVE-2014-9786, CVE-2014-9788, CVE-2014-9779, CVE-2014-9780, CVE-2014-9789, CVE-2014-9793, CVE-2014-9782, CVE-2014-9783, CVE-2014-9785, CVE-2014-9787, CVE-2014-9784, CVE-2014-9777, CVE-2014-9778, CVE-2014-9790, CVE-2014-9792, CVE-2014-9797, CVE-2014-9791, CVE-2014-9796, CVE-2014-9800, CVE-2014-9799, CVE-2014-9801, CVE-2014-9802, CVE-2015-8891, CVE-2015-8888, CVE-2015-8889, CVE-2015-8890 High Yes Elevation of privilege vulnerability in Qualcomm USB driver (Device specific) CVE-2016-2502 High Yes Elevation of privilege vulnerability in Qualcomm Wi-Fi driver (Device specific) CVE-2016-3792 High Yes Elevation of privilege vulnerability in Qualcomm camera driver (Device specific) CVE-2016-2501 High Yes Elevation of privilege vulnerability in NVIDIA camera driver (Device specific) CVE-2016-3793, CVE-2016-3794 High Yes Elevation of privilege vulnerability in MediaTek power driver (Device specific) CVE-2016-3795, CVE-2016-3796 High Yes Elevation of privilege vulnerability in Qualcomm Wi-Fi driver (Device specific) CVE-2016-3797 High Yes Elevation of privilege vulnerability in MediaTek hardware sensor driver (Device specific) CVE-2016-3798 High Yes Elevation of privilege vulnerability in MediaTek video driver (Device specific) CVE-2016-3799, CVE-2016-3800 High Yes Elevation of privilege vulnerability in MediaTek GPS driver (Device specific) CVE-2016-3801 High Yes Elevation of privilege vulnerability in kernel file system (Device specific) CVE-2016-3802, CVE-2016-3803 High Yes Elevation of privilege vulnerability in MediaTek power management driver (Device specific) CVE-2016-3804, CVE-2016-3805 High Yes Elevation of privilege vulnerability in MediaTek display driver (Device specific) CVE-2016-3806 High Yes Elevation of privilege vulnerability in serial peripheral interface driver (Device specific) CVE-2016-3807, CVE-2016-3808 High Yes Elevation of privilege vulnerability in Qualcomm sound driver (Device specific) CVE-2016-2068 High Yes Elevation of privilege vulnerability in kernel (Device specific) CVE-2014-9803 High Yes Information disclosure vulnerability in networking component (Device specific) CVE-2016-3809 High Yes Information disclosure vulnerability in MediaTek Wi-Fi driver (Device specific) CVE-2016-3810 High Yes Elevation of privilege vulnerability in kernel video driver (Device specific) CVE-2016-3811 Moderate Yes Information disclosure vulnerability in MediaTek video codec driver (Device specific) CVE-2016-3812 Moderate Yes Information disclosure vulnerability in Qualcomm USB driver (Device specific) CVE-2016-3813 Moderate Yes Information disclosure vulnerability in NVIDIA camera driver (Device specific) CVE-2016-3814, CVE-2016-3815 Moderate Yes Information disclosure vulnerability in MediaTek display driver (Device specific) CVE-2016-3816 Moderate Yes Information disclosure vulnerability in kernel teletype driver (Device specific) CVE-2016-0723 Moderate Yes Denial of service vulnerability in Qualcomm bootloader (Device specific) CVE-2014-9798, CVE-2015-8893 Moderate Yes Sponsored: Global DDoS threat landscape report
Just need a couple of common bugs, some GPUs and time Android's full-disk encryption on millions of devices can be cracked by brute-force much more easily than expected – and there's working code to prove it. Essentially, if someone seizes your Qualcomm Snapdragon-powered phone, they can potentially decrypt its file system's contents with a friendly Python script without knowing your password or PIN. The tech details Android encrypts a gadget's file system using a randomly generated 128-bit Device Encryption Key aka the DEK.

Android encrypts the DEK using the owner's PIN or password and stores it alongside the encrypted file system in the device's flash storage chips. When you give Android the correct PIN or password, it can decrypt the DEK and use the key to unlock the file system. However, it's not quite that simple: the DEK is actually encrypted using the owner's PIN or password and an encrypted block of data called the KeyMaster Key Blob.

That blob contains a 2,048-bit RSA key generated by a KeyMaster program that runs inside a secured portion of the device's processor.

The KeyMaster creates the RSA key, stores it in the blob, and gives an encrypted copy of the blob to Android. It's important to understand that Android and your mobile apps run in the non-secure portion of the processor.

Android is not allowed to see into the KeyMaster's secure world and therefore it cannot see the RSA key inside the blob.

Android is only given the blob in encrypted form and only the KeyMaster can decrypt it. When you enter your PIN or password, Android takes the encrypted blob, and passes it back to the KeyMaster in the secure portion of the processor along with a scrypt-scrambled copy of your PIN or password.

The KeyMaster privately decrypts the blob using a secret key fused into the processor to obtain the long RSA key. The KeyMaster then, again privately, produces an RSA signature using the scrambled PIN or password and the long RSA key, and sends the signature back to Android.

Android then runs that signature through a series of algorithms to ultimately decrypt the DEK and unlock the device. So: this all hinges on the KeyMaster's blob.

The blob contains the long RSA key that's needed to complete the decryption of the DEK.

Android only has the encrypted blob – and only you have the PIN or password.

And only the KeyMaster can decrypt the encrypted blob. If you can decrypt the blob and extract its RSA key then you're potentially more than half there to decrypting the file system: you can now realistically start brute-forcing the PIN or password to complete the unlocking.
Ideally, you should never be able to get hold of the unencrypted blob.

But... there's always a but. The vulnerabilities Android defines how the KeyMaster should work but leaves the implementation to the hardware manufacturer. Qualcomm provides a KeyMaster for its ARM-compatible Snapdragon system-on-chips that are at the heart of millions and millions of phones, tablets and other gadgets.

The KeyMaster runs in the processor's TrustZone – a special walled-off compartment present alongside various ARM cores.

The operating system runs outside of TrustZone and cannot, ideally, interfere with the secure area.
Special functions, such as encryption and fingerprint scanners, operate in the protected TrustZone. Security researcher Gal Beniamini has been investigating Qualcomm's TrustZone code for a while now, and has documented in detail how he was able to extract the KeyMaster's keys from devices. Qualcomm runs a small kernel in TrustZone to provide what's known as QSEE – the Qualcomm Secure Execution Environment – and little apps are allowed to run in this QSEE space away from Android. Qualy's KeyMaster is a QSEE app.

Beniamini has detailed how it is possible to exploit an Android kernel security hole to load your own QSEE app and then, within that protected space, exploit a privilege-escalation vulnerability in Qualcomm's TrustZone kernel to take complete control of the entire QSEE space. Once you've done that, you can peer inside KeyMaster and extract the unencrypted blob. And with that blob, you can potentially decrypt the encrypted file system by brute-forcing the remaining secret: the PIN or password. Without the blob's secret RSA key, you'd be completely out of luck. It's part security bug, part design blunder: the KeyMaster makes its crucial keys available to software, albeit software within a walled garden, so the aim of the game is to leap over the barriers and snatch the prize within.

A malicious app could start the process, attacking the Android kernel to get into the QSEE zone, or a booby-trapped text message could slip in through StageFright and stab at TrustZone. Alternatively, the FBI, say, could flash a custom Android build to a seized device with a TrustZone environment that extracts the KeyMaster keys, allowing the file system to be unlocked by brute force. "Android uses the same FDE [full-disk encryption] scheme across all devices," Beniamini told The Register. "This FDE scheme relies on the KeyMaster module to 'bind' the key to the hardware of the device. My research has shown that this 'binding' can actually be circumvented on Qualcomm's devices.
It could be the case that this is also possible on devices made by other SoC manufacturers." So... is it patched? Beniamini exploited a chain of security bugs to infiltrate KeyMaster – bugs that have since been patched in the source code: one in January and the other in May. If you're running a Nexus device or otherwise have received and installed the fixes from Google and Qualcomm, then you're safe until the next privilege escalation bugs are found (and there will be more.

There always is). Without these programming flaws, you cannot leap from userspace to the kernel to QSEE to KeyMaster. However, there's a large pool of unpatched Android handsets out there because it's down to the manufacturers and mobile carriers to test, validate and distribute updates to their customers. People's phones and tablets won't trust patches unless they've been signed off by their manufacturers, and Android hardware makers are notoriously slow to do so.

That leaves folks with holes in their handhelds' operating system. A lot of the time, Google can quietly push out patches via Google Play services: the software can install fixes directly from the mothership, bypassing tardy hardware makers. However, problems deep within Android and its drivers – such as the bugs exploited to crack the KeyMaster – cannot be fixed by the Play services, and must be fixed via updates obtained from the manufacturer. When they finally appear, of course. Even if you are patched, this issue isn't going to go away, Beniamini said, because the way the Qualcomm TrustZone operates means that if another privilege escalation hole is found it can be used in the same way. "If anyone finds another TrustZone bug in the KeyMaster module, or manages to elevate privileges to the TrustZone kernel, they'd be able to extract the KeyMaster keys again," he said. "This is really the sore point of it all – it means that the FDE scheme is only as strong as the TrustZone software." Beniamini's exploit code, published on GitHub, checks out according to security experts contacted by The Reg, and the attack does make it possible to brute-force decrypt a phone's file system. Obviously, the stronger the PIN or password, the longer it will take to crack the encryption key – but it's better than trying to crack a 2048-bit RSA key. "I've been contacted by the developer of hashcat, a platform used to rapidly crack various types of hashes and PRFs," Beniamini said. "He said he would like to implement the key derivation function (which is the function being brute-forced) in the hashcat framework.
Such an implementation would be very fast (and even faster once you 'throw' more hardware at it)." Google declined to comment, although pointed out that the issue is patched in the latest build of Android. Qualcomm told The Register that it had been working with Beniamini and Google on the issue after finding the bugs some time ago. "It's an architectural problem in how current Android architecture handles FDE," said Alex Gantman, vice president of engineering at Qualcomm. "We are aware of this and are working with Google to make this more robust in the future." The fear is that a serious change will require new hardware, leaving older customers with insecure handsets.

But Gantman said that there are "things that can be done" with the existing hardware to make this kind of attack a lot less plausible. ®