“Firmware Biopsy: Enterprise Infrastructure Protection”
is a talk on use of CHIPSEC in Google Rapid Response (GRR). Click on the URL in the below tweet for the presentation from Ruxcon:
Tag: Google
Google’s fuzzer-test-suite
fuzzer-test-suite:
This is a set of tests (benchmarks) for fuzzing engines (fuzzers). The goal of this project is to have a set of fuzzing benchmakrs derived from real-life libraries that have interesting bugs, hard-to-find code paths, or other challenges for bug finding tools. The current version supports libFuzzer, in future versions we exect to support AFL and potentially other fuzzers. […]
Duo on ChromeOS Verified Access API
https://twitter.com/jonoberheide/status/776522542773338112
Duo Collaborates With Google to Provide Verified Access for Chrome OS
[…]
Ensuring Trusted Access with Google’s Verified Access API
For the past few months, we’ve worked with Google on testing early versions of the Chrome OS Verified Access API, which is now publicly available and configurable in the Google Apps Admin Panel. Verified Access is a new API that allows Chromebooks to cryptographically attest to the state of certain security properties of the device to a third party – in our case, that third party is actually Duo’s service – for the purposes of making decisions around activities like access control. We use this to reliably assess the security posture of Chromebooks at Duo before they are allowed to access particularly sensitive resources. What does the attestation protocol actually tell us? According to the source code:[…]
https://duo.com/blog/duo-collaborates-with-google-to-provide-verified-access-for-chromeos
http://googleforwork.blogspot.com/2016/09/pushing-the-boundary-of-Chrome-OS-Security-with-Verified-Access.html
UEFI bootloader for Google Fuchsia
Apparently Google is working on a new OS called Fuchsia, which is not based on Linux, Android, or ChromeOS. One of the components of Fuchsia is Magenta.
I just noticed that Magenta has a UEFI-aware bootloader.
https://github.com/fuchsia-mirror/gigaboot20x6
“This project contains some experiments in software that runs on UEFI firmware for the purpose of exploring UEFI development and bootloader development.”
https://github.com/fuchsia-mirror
https://github.com/fuchsia-mirror/magenta
https://github.com/fuchsia-mirror/magenta/blob/master/docs/index.md
https://github.com/littlekernel/lk
Android kernel getting more security features
Android is getting a variety of new security features, including parts of GRSEC’s patch:
https://twitter.com/lattera/status/759453323489443840
https://security.googleblog.com/2016/07/protecting-android-with-more-linux.html
Google fork of CHIPSEC
[[UPDATE: this tweet from answers my below question:
]]
GRR (Google Rapid Response), a remote live forensics for incident response, has forked CHIPSEC and updated it to work with GRR. I wonder if the CHIPSEC team will fold back these changes into the trunk version of CHIPSEC?
Android Verified Boot enforced with 7.0
Sami Tolvanen of Google posted a blog about Android Verified Boot and how things have changed with Android 7.0:
Android uses multiple layers of protection to keep users safe. One of these layers is verified boot, which improves security by using cryptographic integrity checking to detect changes to the operating system. Android has alerted about system integrity since Marshmallow, but starting with devices first shipping with Android 7.0, we require verified boot to be strictly enforcing. This means that a device with a corrupt boot image or verified partition will not boot or will boot in a limited capacity with user consent. Such strict checking, though, means that non-malicious data corruption, which previously would be less visible, could now start affecting process functionality more. By default, Android verifies large partitions using the dm-verity kernel driver, which divides the partition into 4 KiB blocks and verifies each block when read, against a signed hash tree. A detected single byte corruption will therefore result in an entire block becoming inaccessible when dm-verity is in enforcing mode, leading to the kernel returning EIO errors to userspace on verified partition data access. This post describes our work in improving dm-verity robustness by introducing forward error correction (FEC), and explains how this allowed us to make the operating system more resistant to data corruption. These improvements are available to any device running Android 7.0 and this post reflects the default implementation in AOSP that we ship on our Nexus devices.[…]
Full post:
http://android-developers.blogspot.com/2016/07/strictly-enforced-verified-boot-with.html
June Android security update
Google does monthly security updates for Android, but not all carriers take updates [that quickly].
The June update includes multiple hardware-related updates.
https://source.android.com/security/bulletin/2016-06-01.html
https://source.android.com/security/bulletin/
https://groups.google.com/forum/#!forum/android-security-updates
Excerpt of acks to researchers from this month:
We would like to thank these researchers for their contributions:
Di Shen (@returnsme) of KeenLab (@keen_lab), Tencent: CVE-2016-2468
Gal Beniamini (@laginimaineb): CVE-2016-2476
Gengjia Chen (@chengjia4574), pjf (weibo.com/jfpan) of IceSword Lab, Qihoo 360 Technology Co. Ltd.: CVE-2016-2492
Hao Chen, Guang Gong, and Wenlin Yang of Mobile Safe Team, Qihoo 360 Technology Co. Ltd.: CVE-2016-2470, CVE-2016-2471, CVE-2016-2472, CVE-2016-2473, CVE-2016-2498
Iwo Banas: CVE-2016-2496
Jianqiang Zhao(@jianqiangzhao) and pjf (weibo.com/jfpan) of IceSword Lab, Qihoo 360 Technology Co. Ltd.: CVE-2016-2490, CVE-2016-2491
Lee Campbell of Google: CVE-2016-2500
Maciej Szawłowski of the Google Security Team: CVE-2016-2474
Marco Nelissen and Max Spector of Google: CVE-2016-2487
Mark Brand of Google Project Zero: CVE-2016-2494
Mingjian Zhou (@Mingjian_Zhou), Chiachih Wu (@chiachih_wu), and Xuxian Jiang of C0RE Team: CVE-2016-2477, CVE-2016-2478, CVE-2016-2479, CVE-2016-2480, CVE-2016-2481, CVE-2016-2482, CVE-2016-2483, CVE-2016-2484, CVE-2016-2485, CVE-2016-2486
Scott Bauer (@ScottyBauer1): CVE-2016-2066, CVE-2016-2061, CVE-2016-2465, CVE-2016-2469, CVE-2016-2489
Vasily Vasilev: CVE-2016-2463
Weichao Sun (@sunblate) of Alibaba Inc.: CVE-2016-2495
Xiling Gong of Tencent Security Platform Department: CVE-2016-2499
Zach Riggle (@ebeip90) of the Android Security Team: CVE-2016-2493
ARM on OEM impact of Android apps on Chromebooks
bfuller has a post ARM’s Android Community blog, with a whitepaper for OEMs on how to deal with Google making Android apps run on ChromeOS systems:
Google on May 19 announced that Android apps are coming to Chromebook. Here is a backgrounder on what the move means for developers, OEMs and consumers. […] The move is likely to have a profound impact on the Chromebook market but also more broadly on clamshell, two-in-one and hybrid form factors. In some ways, the move echoes the impact that the Android development community and ARM ecosystem had in 2009, at the dawn of the smart phone era. What exactly the announcement mean for developers, OEMs and consumers? We’ve posted a detailed article (Android Apps on Chromebook.pdf) that dives into the possibilities and implications of making Android apps available on Chromebooks. Check it out and let us know how the news will affect your work! […]
https://community.arm.com/groups/android-community/blog/2016/05/19/android-apps-on-chromebook-what-it-means-for-developers-oems
https://chrome.googleblog.com/2016/05/the-google-play-store-coming-to.html
https://community.arm.com/docs/DOC-11574
Security updates in Android N
Lucian Armasu has a story in Toms Hardware about Android N security changes, summarizing a presentation from Adrian Ludwig of Android at the recent Google I/O event. The story has a link to the Google I/O video, as well. Outline of Lucian’s story:
Hardware-Backed Keystore (Now Mandatory)
Fingerprint And Smart Lock Authentication
Secure Networking
Storage Encryption
Strictly Enforced Verified Boot
Checking Device Health
Sandboxing
Other System Restrictions & Improvements
“[…] Ludwig said that a major security feature of Android these days is the hardware-backed ‘keystore’, which is available in the vast majority of Android devices thanks to various implementations of ARM’s TrustZone. Although TrustZone has been mainly implemented by chip makers and OEMs to enable stricter DRM protection, Google started making it available to application developers in the past few years. […]”
“[…] If in Android M the phone would warn the user only that the boot was modified by unknown code, in version N the device will not boot if the boot process has been maliciously modified. Google also introduced bit-level error correction in the verified boot feature, which can erase changes that would, for instance, keep a device rooted after it’s been rooted. […]”
Full story:
http://www.tomshardware.com/news/google-android-n-security-improvements,31846.html
Android Nexus 5 Monitor Mode
Vincent recently tweeted this pointer to a blog from Frédéric Basse, talking about Android Nexus 5’s Monitor Mode:
Analysis of Nexus 5 Monitor mode
This article will first describe how to locate the Monitor mode code in Nexus 5 firmware (hammerhead-ktu84p-factory-35ea0277, bootloader-hammerhead-hhz11k : c32f8bec310c659c1296739b00c6a8ac). Then, we will try to understand what it does (its functionalities). Finally, you will have to find bugs by yourself because I didn’t find any…so far !
[…]
Full article:
http://www.fredericb.info/2014/12/analysis-of-nexus-5-monitor-mode.html?spref=tw
OpenREIL
Dmytro Oleksiuk has a project called OpenREIL, an open source library and tools for Reverse Engineering Intermediate Language (REIL).
REIL was initially developed by Zynamics as part of their BinNavi framework, proprietary code analysis software written in Java. […] However, after Zynamics was acquired by Google they abandoned BinNavi, so, I decided to develop my own implementation of REIL. I made it relatively small and portable in comparison with original, the translator itself is just a single library written in C++, it can be statically linked with any program for static or dynamic code analysis. The higher level API of OpenREIL is written in Python, so, it can be easily utilized in plugins and scripts for your favourite reverse engineering tool (almost all modern debuggers and disassemblers has Python bindings). OpenREIL is not a 100% compatible with Zynamics REIL, it has the same ideology and basics, but there’s some changes in IR instruction set and representation of the traget hardware platform features. […]
Google’s new People API
Perhaps slightly off-topic, but I suspect it’ll be used by multiple IoT devices… Excerpting from Eric Zeman’sProgrammableWeb article:
Google today announced the People API, a single API it hopes will eventually be able to replace both the existing Google+ APITrack this API and Google Contacts APITrack this API. The People API will allow developers to snag connection data from authenticated Google users with a single call, rather than multiple calls — and that’s good news for everyone. As Google explains it, the People API will eclipse the Google+ and Contacts APIs because it uses the newest protocols and technologies. The Contacts API, for example, uses the somewhat dated GData protocol. The People API can reach into users’ private contact lists (as long as permitted) to see if those contacts are linked to other, public profiles. Google says properly granted scopes will return results as a people.connections.list object, which can then be used to snag more data about the person in question. In other words, it will allow developers to connect more of the dots that exist between Google users. […]
https://developers.google.com/people/api/rest/
https://people.googleapis.com
https://developers.google.com/people/
http://m.androidcentral.com/androids-new-people-api-helps-developers-more-easily-tap-contact-data
https://developers.google.com/+/web/api/rest/latest/people
http://www.programmableweb.com/news/google-people-api-lets-devs-poke-through-users-contacts/2016/02/10
February’s Google Nexus security bulletin is out
The Google Nexus Security team has released their monthly security bulletin.
We have released a security update to Nexus devices through an over-the-air (OTA) update as part of our Android Security Bulletin Monthly Release process. The Nexus firmware images have also been released to the Google Developer site. Builds LMY49G or later and Android M with Security Patch Level of February 1, 2016 or later address these issues. Refer to the Nexus documentation for instructions on how to check the security patch level.
[…]
We would like to thank these researchers for their contributions:
* Android and Chrome Security Team: CVE-2016-0809, CVE-2016-0810
* Broadgate Team: CVE-2016-0801, CVE-2015-0802
* David Riley of the Google Pixel C Team: CVE-2016-0812
* Dongkwan Kim (dkay@kaist.ac.kr) of System Security Lab, KAIST: CVE-2015-6614
* Gengjia Chen (@chengjia4574) of Lab IceSword, Qihoo 360: CVE-2016-0805
* Hongil Kim (hongilk@kaist.ac.kr) of System Security Lab, KAIST: CVE-2015-6614
* Qidan He (@Flanker_hqd) of KeenLab (@keen_lab), Tencent: CVE-2016-0811
* Seven Shen (@lingtongshen) of Trend Micro (www.trendmicro.com): CVE-2016-0803
* Weichao Sun (@sunblate) of Alibaba Inc: CVE-2016-0808
* Zach Riggle (@ebeip90) of the Android Security Team: CVE-2016-0807
[…]
See the full bulletin for specifics on each of the CVEs:
https://source.android.com/security/bulletin/2016-02-01.html
reversing Google Nest devices
Kamil Domański has an article on Google Nest-flavored IoT reversing:
In the buzzword-powered world of IoT there doesn’t really seem to be as much innovation as some would have you think. The hundredth “smart” camera, door lock or lamp don’t really disrupt much, yet some players in this space seem to be getting far ahead of the others. A notable player in this space is Nest Labs who after their acquisition by Google rose to be one of the most prominent brand names in this space, now a subsidy of Alphabet. Here at Protonet we consider owning and having access to your own data as one of our core values – thus as much as we admire Alphabet’s tech, we’re sceptical about it’s cloud only approach to smart home products. It’s not much of a surprise then that we picked Nest products for our research efforts when looking into integration of different kinds of smart devices. […]
Full article: here (WordPress doesn’t like Tumblr.com URLs, refuses to show them.)
Google Android Nexus debug cable is open source
Google has specs for the Nexus debug cable:
USB debug cable design documents: Eagle schematics and PCB, gerber files, and BOM for a debug cable
for the headset serial port found on most Nexus devices.
https://android.googlesource.com/device/google/debugcable/+/master
Google Ubiquity and IoT security
Google’s Ubiquity Dev Summit just ended, some of the video is online. There is one talk on IoT security:
https://ubiquity.withgoogle.com/
https://ubiquity.withgoogle.com/stream
https://ubiquity.withgoogle.com/schedule
“Brillo has a defense-in-depth strategy to device security built around verified boot, software fault isolation, and field updates of devices. Paul Covell explains the architecture of each of these mechanisms and how they work together to help Brillo devices be more resistant to exploit and create mechanisms for recovery if an exploit occurs.“
RISC-V/LowRISC update
The recent RISC-V workshop is over, presentations are online, videos are not yet online:
http://riscv.org/workshop-jan2016.html
http://riscv.org/
RISC-V and coreboot:
Click to access Tues1345%20riscvcoreboot.pdf
RISC-V and UEFI:
Click to access Tues1415%20RISC-V%20and%20UEFI.pdf
There is some post-workshop coverage here:
https://blog.riscv.org/2016/01/3rd-risc-v-workshop-presentations-breakouts/
http://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-one/
http://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-two/
http://www.eetimes.com/document.asp?doc_id=1328620&
LowRISC, a related project to RISC-V is also making progress. From the below EE Times article:
“The LowRISC project at the University of Cambridge is attracting interest as the likely first source of real development hardware. The team which includes members of the Raspberry Pi project hopes to have first silicon this year and plans to make development boards available in 2017, likely for $50-100.”
http://www.eetimes.com/document.asp?doc_id=1328620&
I missed this news, it is interesting to see Google, HP, and Oracle getting involved with RISC-V.
http://www.eetimes.com/document.asp?doc_id=1328561&
exploitee.rs: GoogleTV hackers
I just noticed Exploitee.rs:
“We are a group of people who are interested in getting full access to the GoogleTV environment.”
https://twitter.com/reversemode/status/679761372268380160
Here’s an example from their blog:
https://blog.exploitee.rs/2015/gaining-root-on-the-google-onhub/
Google releases Chrome OS security update
US-CERT reports that Google has Released Security Updates for Chrome and Chrome OS
“Google has released security updates to address vulnerabilities in Chrome and Chrome OS. Exploitation of one of these vulnerabilities may allow a remote attacker to take control of an affected system. Updates available include:
* Chrome 46.0.2490.86 for Windows, Mac and Linux
* Chrome 46.0.2490.82 for all OS devices
Users and administrators are encouraged to review the Chrome page and Chrome OS page and apply the necessary updates.”
More Info:
http://googlechromereleases.blogspot.com/2015/11/stable-channel-update-for-chrome-os.html
http://googlechromereleases.blogspot.com/2015/11/stable-channel-update.html
https://www.us-cert.gov/ncas/current-activity/2015/11/11/Google-Releases-Security-Updates-Chrome-and-Chrome-OS
Firmware Security 
You must be logged in to post a comment.