Android attestation API

Shawn Willden of Google recently posted a message to the Android Security Discussions group. Someone had asked if, like a PC, Android smartphones have a TPM or Trusted Execution Environment (TEE), and if this included a public remote attestation API. Shawn’s response:

“One of the features I’m working on adding to Android TEEs for N is an attestation API. It will be implemented in our TEE, Qualcomm’s, Trustonic’s, etc. However, that will only assure the relying party that the device attesting has an officially-blessed TEE, and that the Android OS that was booted was an officially-blessed image as well. It can’t say anything about the state of Android, whether or not it has been compromised in some way that doesn’t involve modifying the boot images. The SafetyNet attestation can theoretically provide some level of assurance that the device is not compromised, though at the moment I believe it really only validates that the device is not an emulator and that it hasn’t been rooted in an obvious way.”

For more information: see the October 25th posting from Shawn on:
http://groups.google.com/group/android-security-discuss

Google to merge Android and ChromeOS?

http://www.linux.com/news/embedded-mobile/mobile-linux/864465-despite-google-denials-chrome-os-and-android-seem-destined-for-merger

http://chrome.blogspot.com/2015/11/chrome-os-is-here-to-stay.html

Personally, I’d like to see Android Verified Boot and Chrome OS Verified Boot unified! 🙂

 

Android Nexus security updates for November

Google is continuing it’s new policy of monthly Android updates for it’s Nexus line.

CVE-2015-6608, Critical, Remote Code Execution Vulnerabilities in Mediaserver
CVE-2015-6609, Critical, Remote Code Execution Vulnerability in libutils
CVE-2015-6611, High, Information Disclosure Vulnerabilities in Mediaserver
CVE-2015-6610, High, Elevation of Privilege Vulnerability in libstagefright
CVE-2015-6612, High, Elevation of Privilege Vulnerability in libmedia
CVE-2015-6613, High, Elevation of Privilege Vulnerability in Bluetooth
CVE-2015-6614, Moderate, Elevation of Privilege Vulnerability in Telephony

https://groups.google.com/forum/#!msg/android-security-updates/n1aw2MGce4E/jhpVEWDUCAAJ
https://source.android.com/devices/tech/security/enhancements/enhancements60.html

In somewhat-related Android security news, there is a new design-time vulnerability:

http://blog.trendmicro.com/trendlabs-security-intelligence/setting-the-record-straight-on-moplus-sdk-and-the-wormhole-vulnerability/
http://www.itproportal.com/2015/11/03/android-sdk-vulnerability-leaves-100-million-users-at-risk/

 

Android IoT: Google Brillo and Weave

Google has began an invite program for their Brillo/Weave IoT project, which they announced earlier this year at Google I/O:

Brillo:

“Since May, we’ve opened up the Brillo operating system (OS) and Weave communication platform to early access partners. Today, we’re extending this to the broader developer community as part of our invite program. Read on to find out how you can receive an invitation. Brillo brings the simplicity and speed of software development to hardware by offering you a lightweight embedded OS based on Android, core services, a developer kit, and a developer console. You can choose from a variety of hardware capabilities and customization options, quickly move from prototype to production, and manage at scale with over the air (OTA) updates, metrics, and crash reporting.”

Weave:

“Once you’ve built your connected device, you’ll need to find a way for it to communicate with other devices and allow users to interact with it. That’s where Weave comes in. With Weave, you can build interoperable communications directly into your devices. Weave provides a messaging service that enables phones and devices to talk to each other locally and remotely through the cloud. The Weave cloud server handles remote communication and access to your web-connected device, safely and at scale. With Weave you also get a set of services to securely set up the device and provide controlled access. Additionally, Weave works seamlessly with, and is actually built right into, Brillo; but, you can also use Weave libraries with your existing Linux-based OS.”

Intel already has their Edison board ready for Brillo:

http://newsroom.intel.com/community/intel_newsroom/blog/2015/10/27/intel-edison-module-offers-brillo-support-at-launch
https://software.intel.com/en-us/blogs/2015/10/27/intel-edison-board-and-brillo

“The Intel Edison compute module is one of the first platforms to support Brillo, which Google released source code for today via an invitation program. Newegg will be offering a Brillo-compliant solution built upon the Intel Edison kit for Arduino. Intel expects to support Brillo on additional SoCs (system-on-chip) and IoT maker boards in the future.”

More Information:

http://www.forbes.com/sites/janakirammsv/2015/10/29/google-brillo-vs-apple-homekit-the-battleground-shifts-to-iot/
http://liliputing.com/2015/10/google-launches-android-based-brillo-os-for-internet-of-things.html
http://www.androidauthority.com/imaginations-new-ci40-creator-iot-board-will-run-brillo-from-google-651920/

Android-based "Brillo" IoT OS arrives with hacker SBC support

Google invites developers to its Brillo IoT platform

Android 6.0 OEMs: support Verified Boot

Multiple news sites have a story about Android 6.0 and Google’s new security requirements for OEMs, such as including Android Verified Boot.

http://www.tomshardware.com/news/marshmallow-encryption-fingerprints-verified-boot,30369.html

http://www.zdnet.com/article/google-now-requires-full-device-encryption-on-new-android-6-0-devices/

http://www.androidauthority.com/new-google-oem-marshmallow-requirements-650266/

Android Security: Q3 Quarterly Update

Adrian Ludwig of Google posted a message to the android-security-discuss mailing list with a quarterly summary of security events. I’m not going to bother excerpting this!, I’m just going to post the entire message body:

TL;DR I’m going to start sending out a quarterly summary of things the major events going on in Android Security. Wow, did I pick a doozey of a quarter to start doing this.

Below, I’ve compiled my top 10 android security events and activities from the Q3, 2015.  The last 3 months have been amazing — any one of these might have been the most important item for Android Security during most quarters. But all of this really did happen in just the last three months.

1. Monthly updates – Announced Nexus support policy with monthly security updates for Nexus <http://officialandroid.blogspot.com/2015/08/an-update-to-nexus-devices.html&gt;. Pushed Samsung <http://www.androidcentral.com/samsung-plans-offer-new-security-updates-every-month-its-android-devices&gt; and LG <http://www.engadget.com/2015/08/07/lg-stagefright-monthly-security-updates/&gt; to make similar announcement (albeit still not realized).  Shipped three updates <https://developers.google.com/android/nexus/images&gt; to Nexus, GPE, Android One and published the corresponding security bulletins <https://groups.google.com/forum/#!forum/android-security-updates&gt;.We also expanded to Kirkland team and began to grow the team to handle our increasing incident response needs <http://go/android-vulns-dashboard&gt;.

2. Unprecedented partner engagement in security – Executive meetings on security with all major US carriers and top 5 OEMs. Worked with APE / TAM / BD to build program for Ecosystem-wide Monthly Security updates <http://go/manic-monday-pitch&gt;, rolled out our security program to all carriers, OEMs, and began to track rollouts <https://dashboards.corp.google.com/#/google::_45984543_fda2_458b_9a8a_3fe0c1130981> of security patches to devices. Here are highlights from a recent program review <https://docs.google.com/presentation/d/1c6xYbGkcIlHD-RPsv00U4vTMrzl4_CuOd-eJrU6Lf4M/edit#slide=id.g702e6832b_0_0&gt;.

3. Stagefright. Stagefright Code Yellow <http://go/stagefright-cy-track&gt;. Media Server Bugs and Hackathon <https://docs.google.com/document/d/1icuQabxBlBBfjjP967YMLliIdSSm798BO20xdYA8q9Y/edit#heading=h.enzv5yxtjeu3&gt;. Also, thanks to aarya@ of Chrome Security for driving that continued expansion of fuzzing efforts <https://docs.google.com/a/google.com/presentation/d/1docwgWwqZL0wEO5R0U5oRyMdnUhg9a3HMhmb-e5vyTM/edit?usp=drive_web&gt;.

4. Android M Security Enhancements <https://docs.google.com/presentation/d/1JfRZ5P-HmuaKJvN3SgZmXWhfoC3sirr8OVtDXPRBQZk/edit#slide=id.gaf51a6178_1_132>- I can’t believe this is #4. We shipped Verified Boot. Monthly Patch String. SeLinux IOCTL filtering. UsesClearTextTraffic. SELinux User separation. The broader Android team also shipped a major overhaul of permissions, fingerprint API, adoption of SD cards, protection for USB connections, and more.

5. Results from Android Security Regards Program <https://www.google.com/about/appsecurity/android-rewards/&gt; – Android Security Rewards launched on June 16 <https://googleonlinesecurity.blogspot.com/2015/06/announcing-security-rewards-for-android.html&gt; and by October 1, we’ve paid out over $100,000 for over 60 issues.

6. Massive Increase in Public Outreach — aludwig @ Blackhat (slides <https://docs.google.com/presentation/d/1U35ilLs3ca8AHNYXKZgl14VjS5Q-RSx3GNVQqCGQWkQ/edit&gt;, press), jeffv@ about ioctl filter <https://docs.google.com/a/google.com/presentation/d/1_meUW-MtHdCQC2YuWnrtJ7W6WXh7CTxfHz_N0TksRY4/edit?usp=drive_web&gt; at Linux Security Summit, paullawrence@ and mhalcrow@ about encryption <https://docs.google.com/a/google.com/presentation/d/1xD2Vs5hHkY8GZB4Y72QAxsPf5sraAAQmse_3IAS2UA4/edit?usp=drive_web&gt; at Linux Security Summit, nnk@ Android Security Symposium  in Vienna(slides <https://docs.google.com/a/google.com/presentation/d/1-BWUaMldBoTzd0Vx9BnjWFP69E3xF1Hk-52s2dFcioo/edit?usp=drive_web&gt;), sporst@ on Russian Malware cleanup at Virus Bulletin (slides <https://docs.google.com/presentation/d/1CrqdAm7WKAXsMja1VHVXEVGbg1vUzvoyhC5qCrqiqsY/edit&gt;, video, press <http://qz.com/514720/google-just-revealed-its-android-security-team-detected-and-defeated-a-steep-rise-in-mobile-banking-fraud-in-russia/&gt;), cbrubaker@ on NoGotofail at University of Utah (slides <https://docs.google.com/a/google.com/presentation/d/12uJxPosU_dI-X4XUQZO2BwPXWl406ny-pGWN3xFC3JI/edit?usp=sharing&gt;), smel@ spoke at Johns Hopkins (slides<https://docs.google.com/presentation/d/1dJWxs7GNUTSABYu08Yt-2eQXDaWBnTFA3DYIDGM1WDk/edit#slide=id.gca06805cf_17_22&gt;)

7. Operational Focus on Malware in Play – Monthly reviews of top PHA installs (July <https://docs.google.com/a/google.com/document/d/1vwTMvOwL4I08GrB9dyLC7ex9fg2ydeqLEg3UBh3XuT4/edit?usp=sharing&gt;, August <https://docs.google.com/document/d/197_ELrS8zhZhGxglF2aSaQq2P_0YBdDhkrlgDG5m_x4/edit&gt;, September <https://docs.google.com/document/d/1lcKEIc3JySPryR2YhlNmNdgquitfQWF9qO-aIaHUCRc/edit?ts=5612e47f&gt;) have helped drive our goal of less than 1 million installs being a PHA. (currently, the number is ~500 per million <http://go/phastats&gt;)

8. Scale up of SafetyNet Attestation (including launch of Android Pay). See recent Program Review <https://docs.google.com/presentation/d/1SHeAt7bQX_OAoe99lwfn5IP9SSKyed7WJOWM-_B9v18/edit&gt; for more details.

9. Greenhat <http://go/greenhat&gt; – 2 day, google-wide summit with the best of Android Security.  All the content  and recordings have been stored here <https://drive.google.com/a/google.com/folderview?id=0B47yL4yVz8b3flhxSkRiemUyQ1dHRDFZblloYm9hZ3doWmJOQzFDTHAwa1RFekdRVExEVXM&usp=sharing&gt;.

10. Last, but not least: Stinknet <http://go/stinknet&gt;. Publicly known as Ghost Push <http://venturebeat.com/2015/09/18/cheetah-mobile-ghost-push-android-virus-infects-600k-users-a-day-with-unwanted-apps/&gt;, (mostly) outside of Google Play we’re currently battling the largest coordinated rooting malware attack we’ve seen against Android. (We’re slowly winnning <http://go/stink&gt;, but this will likely be a highlight again next quarter.)

Anyhow, those are just a few of the big things we’ve been up to recently.

http://groups.google.com/group/android-security-discuss.

Nexus status update

Tom’s Hardware has an article with an interview of a few Nexus engineers, talking about upcoming releases:

Nexus Engineers Reveal More Nexus 5X, Nexus 6P Details
by Lucian Armasu

Four members of the Google Nexus team, including Hiroshi Lockheimer, David Burke, Krishna Kumar and Sandeep Waraich, took the time to answer questions from Nexus 5X and Nexus 6P fans about the two new phones. Here’s a summary of the most important details. […]

http://www.tomshardware.com/news/nexus-5x-nexus-6p-ama,30208.html#xtor=RSS-999

Android SafetyNet and Device Verification

A few Android news sites have a story about why Google Pay won’t work on rooted Android devices, and how Jason Clinton of Google posted a message on the XDA forum with more details on why this happens. Excerpt of Jason’s post:

While the platform can and should continue to thrive as a developer-friendly environment, there are a handful of applications (that are not part of the platform) where we have to ensure that the security model of Android is intact. That “ensuring” is done by Android Pay and even third-party applications through the SafetyNet API. As you all might imagine, when payment credentials and–by proxy–real money are involved, security people like me get extra nervous. I and my counterparts in the payments industry took a long, hard look at how to make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model. We concluded that the only way to do this for Android Pay was to ensure that the Android device passes the compatibility test suite–which includes checks for the security model. The earlier Google Wallet tap-and-pay service was structured differently and gave Wallet the ability to independently evaluate the risk of every transaction before payment authorization. In contrast, in Android Pay, we work with payment networks and banks to tokenize your actual card information and only pass this token info to the merchant. The merchant then clears these transactions like traditional card purchases.

Full post:
http://forum.xda-developers.com/google-nexus-5/general/android-pay-custom-rom-t3199843/post62981452#post62981452

A bit more on Android SafetyNet API, from their web site:

“SafetyNet provides services for analyzing the configuration of a particular device, to make sure that apps function properly on a particular device and that users have a great experience. The service provides an API your app can use to analyze the device where it is installed. The API uses software and hardware information on the device where your app is installed to create a profile of that device. The service then attempts to match it to a list of device models that have passed Android compatibility testing. This check can help you decide if the device is configured in a way that is consistent with the Android platform specifications and has the capabilities to run your app.”

https://source.android.com/compatibility/cts/index.html
https://developer.android.com/training/safetynet/index.html

http://news.softpedia.com/news/google-explains-why-android-pay-won-t-work-on-rooted-phones-492854.shtml

Google security engineer explains why Android Pay doesn’t work on rooted devices

 

Ext4 encryption

QuarksLab has a new blog on encryption support of Linux’s Ext4 file system:

Excerpting the beginning of the post:

Linux 4.1 has arrived with a new feature for its popular ext4 filesystem: filesystem-level encryption! This feature appears to have been implemented by Google since they plan to use it for future versions of Android and Chrome OS. Android filesystem encryption currently relies on dm-crypt. Google’s motivations for pushing encryption to ext4 seem:
* To avoid using a stacked filesystem design (for better performance?).
* To encrypt data with integrity.
* To allow multiple users to encrypt their files with different keys on the same filesystem.

More Information:

http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html

Also see this article from April:
https://lwn.net/Articles/639427/

UPDATE: See-also this recent talk from Google at the 2015 Linux Security Summit:
Encrypting Android Devices
Paul Lawrence and Mike Halcrow, Google

Click to access halcrow.pdf

Linux Security Summit 2015 proceedings available

As part of LinuxCon North America, the Linux Security Summit recently finished, and presentations are now available (I omitted the few talks which had no presentations from below list):

* Keynote: Giant Bags of Mostly Water – Securing your IT Infrastructure by Securing your Team, Konstantin Ryabitsev, Linux Foundation
* CC3: An Identity Attested Linux Security Supervisor Architecture, Greg Wettstein, IDfusion
* SELinux in Android Lollipop and Android M, Stephen Smalley, NSA
* Discussion: Rethinking Audit, Paul Moore, Red Hat
* Assembling Secure OS Images, Elena Reshetova, Intel
* Linux and Mobile Device Encryption, Paul Lawrence, Mike Halcrow, Google
* Discussion: Core Infrastructure Initiative, Emily Ratliff, Linux Foundation
* Security Framework for Constraining Application Privileges, Lukasz Wojciechowski, Samsung
* IMA/EVM: Real Applications for Embedded Networking Systems, Petko Manolov, Konsulko Group, Mark Baushke, Juniper Networks
* Ioctl Command Whitelisting in SELinux, Jeffrey Vander Stoep, Google
* IMA/EVM on Android Device, Dmitry Kasatkin, Huawei Technologies
* Subsystem Update: Smack, Casey Schaufler, Intel
* Subsystem Update: AppArmor, John Johansen, Canonical
* Subsystem Update: Integrity, Mimi Zohar, IBM
* Subsystem Update: SELinux, Paul Moore, Red Hat
* Subsystem Update: Capabilities, Serge Hallyn, Canonical
* Subsystem Update: Seccomp, Kees Cook, Google
* Discussion: LSM Stacking Next Steps, Casey Schaufler, Intel

http://kernsec.org/wiki/index.php/Linux_Security_Summit_2015/Schedule

Android Marshmallow released

Google recently released Developer Preview 3 of Android 6.0 SDK, Android “M”, Marshmallow. So far, I don’t see any firmware-centric changes yet…

http://developer.android.com/preview/support.html#preview3-notes
http://android-developers.blogspot.com/2015/08/m-developer-preview-3-final-sdk.html

https://en.wikipedia.org/wiki/Android_Marshmallow

 

Google open sources BinNavi

https://github.com/google/binnavi

Google acquired Zynamics in 2011. Today, Google open sourced BinNavi, a GUI IDE for binary analysis! It is not fully open source, see the readme on github for details.

http://www.zynamics.com/binnavi.html

 

Google revises Nexus update policy

Last week, Adrian Ludwig (Lead Engineer for Android Security) and Venkat Rapaka (Director of Nexus Product Management) posted a blog entry on the Official Android blog, announcing a change to the Nexus update policy:

“Nexus devices have always been among the first Android devices to receive platform and security updates. From this week on, Nexus devices will receive regular OTA updates each month focused on security, in addition to the usual platform updates. The first security update of this kind began rolling out today, Wednesday August 5th, to Nexus 4, Nexus 5, Nexus 6, Nexus 7, Nexus 9, Nexus 10, and Nexus Player. This security update contains fixes for issues in bulletins provided to partners through July 2015, including fixes for the libStageFright issues. At the same time, the fixes will be released to the public via the Android Open Source Project. Nexus devices will continue to receive major updates for at least two years and security patches for the longer of three years from initial availability or 18 months from last sale of the device via the Google Store.”

Nexus aside, I hope other carriers also have clear policies about updates.

Read the full announcement here:
http://officialandroid.blogspot.com/2015/08/an-update-to-nexus-devices.html?m=1

Apple EFI vulnerabilities: CVE-2015-3693 and CVE-2015-3692

From the security-announce@lists.apple.com announce list, Apple has an EFI update for multiple systems, available from the App Store. Two CVEs are listed:

APPLE-SA-2015-06-30-3 Mac EFI Security Update 2015-001

Mac EFI Security Update 2015-001 is now available and addresses the following:

EFI
Available for:  OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5
Impact:  A malicious application with root privileges may be able to modify EFI flash memory
Description:  An insufficient locking issue existed with EFI flash when resuming from sleep states. This issue was addressed through improved locking.
CVE-ID
CVE-2015-3692 : Trammell Hudson of Two Sigma Investments, Xeno Kovah and Corey Kallenberg of LegbaCore LLC, Pedro Vilaca

EFI
Available for:  OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5
Impact:  A malicious application may induce memory corruption to escalate privileges
Description:  A disturbance error, also known as Rowhammer, exists with some DDR3 RAM that could have led to memory corruption. This issue was mitigated by increasing memory refresh rates.
CVE-ID
CVE-2015-3693 : Mark Seaborn and Thomas Dullien of Google, working from original research by Yoongu Kim et al (2014)

More Information:
https://support.apple.com/en-us/HT204934
https://lists.apple.com/mailman/options/security-announce/

coreboot gets Rockchip ‘Veyron Shark’ support

As reported today by Michael Larabel at Phoronix, coreboot recently got support for the Rockchip ‘Veyron Shark’ ARM SoC , used for Chromebook/Chromebox, with code from Google and Rock Chip.

To quote Phoronix:

“Julius Werner of Google’s Chromium team added the Veyron Shark mainboard into Coreboot Git. Shark is in turn is based off a copy of the Coreboot code for Veyron Speedy. Some of the code comes from Google while the rest is from Rockchip Inc. Rockchip’s latest chip series is the RK33xx that is based on an octa-core Cortex-A53 design with a GPU supporting OpenGL ES 3.1 and capable of HDMI 2.0 and 4Kx2K @ 60 FPS H.264/H.265 real-time video playback.”

Rock Chip nor coreboot didn’t didn’t consider this newsworthy, no press release. I’m grateful that Phoronix has such an efficient news gathering system, especially for tracking new features in coreboot.

More Information:

http://www.phoronix.com/scan.php?page=news_item&px=Veyron-Shark-In-Coreboot

Google Auron support added to Coreboot

As reported yesterday by Michael Larabel at Phoronix, coreboot recently got support for the Intel-based Google Broadwell ‘Auron’ board. To quote Phoronix:

“Support for Auron has been added in Coreboot Git. Auron is the Google Broadwell Reference Motherboard, which in turn is based on Google’s Peppy. More Broadwell designs are emerging and soon this latest-generation Intel processor will finally be out for desktops. The Google Auron is their reference board for this latest micro-architecture.”

More Information:

http://www.phoronix.com/scan.php?page=news_item&px=Auron-Coreboot-Broadwell

Book Review: Embedded Firmware Solutions

Embedded Firmware Solutions: Development Best Practices for the Internet of Things
APress Media
ISBN 978-4842-0071-1
February 2015
Jiming Sun, Marc Jones, Stefan Reinauer, Vincent Zimmer
http://www.apress.com/9781484200711

[I recently finished reading this book. Sadly, I didn’t know about it until the other day, after my LinuxFestNorthWest talk on firmware security tools, someone from Sage pointed out that I omitted this from my More Information slides.]

If you care about firmware development — or just understanding current firmware architecture — you should have this book. It is the only current book with information about modern firmware in use today. The authors are all experienced and well-known firmware developers, including members of the Coreboot and UEFI teams, and there is also an impressive list of tech reviewers. There are 4 areas that this book focuses on:
* Intel Firmware Support Package (FSP), and it’s use in Coreboot and UEFI.
* UEFI and it’s dev platform.
* Coreboot and Chrome use of it.
* Intel Quark and UEFI firmware.

Intel Press has a handful of other UEFI books, but they are years old, this book is only a few months old, and has fresher details on UEFI. I don’t know of any other book with this kind of information on Coreboot, or on Intel FSP. There are a variety of books on Intel’s Minnowboard and Quark/Galileo IoT hardware: most of those books talk about how to write user-level apps, this is the only book that talks about updating the firmware of Intel IoT devices.

I’m looking forward to a second edition in a year or so, once tech changes enough.