Security Blog
The latest news and insights from Google on security and safety on the Internet
Evolving the Safe Browsing API
May 20, 2016
Posted by Emily Schechter and Alex Wozniak, Safe Browsing Team
We're excited to announce the launch of the new
Safe Browsing API version 4
. Version 4 replaces the existing Safe Browsing API version 3. With the launch of v4, we’re now starting the deprecation process for v2-3: please transition off of these older Safe Browsing protocol versions as soon as possible and onto protocol version 4.
Safe Browsing
protects well over two billion internet-connected devices from threats like malware and phishing, and has done so for over a decade. We launched v1 of the Safe Browsing API
in 2007
to give developers a simple mechanism to access Google’s lists of suspected unsafe sites.
The web has evolved since then and users are now increasingly using the web from their mobile devices. These devices have constraints less common to traditional desktop computing environments: mobile devices have very limited power and network bandwidth, and often poor quality of service. Additionally, cellular data costs our users money, so we have a responsibility to use it judiciously.
With protocol version 4, we’ve optimized for this new environment with a clear focus on maximizing protection per bit, which benefits all Safe Browsing users, mobile and desktop alike. Version 4 clients can now define constraints such as geographic location, platform type, and data caps to use bandwidth and device resources as efficiently as possible. This allows us to function well within the much stricter mobile constraints without sacrificing protection.
We’ve been using the new protocol since December via the
Safe Browsing client on Android
, which is part of Google Play Services. The first app to use the client is Chrome, starting with version 46: we’re already protecting hundreds of millions of Android Chrome users by default.
We’ve Done Most Of The Work For You Already
A single device should only have a single, up-to-date instance of Safe Browsing data, so we’re taking care of that for all Android developers. Please don’t implement your own Version 4 client on Android: we’re working on making a simple, device-local API available to prevent any resource waste on device. We’ll announce the availability of this new device-local API as soon as possible; in the meantime, there’s no need to develop a Version 4 client on your own. For those who operate in less resource-constrained environments, using the Safe Browsing Version 4 API directly allows you to:
Check pages against the Safe Browsing lists based on platform and threat types.
Warn users before they click links that may lead to infected pages.
Prevent users from posting links to known infected pages
To make Safe Browsing integration as simple as possible, we’re also releasing a
reference client implementation
of the new API today, written in Go. It also provides a Safe Browsing HTTP proxy server, which supports JSON.
It’s easy to start protecting users with the new Version 4 of the Safe Browsing API.
Sign up for a key
and
let us know what you think
!
Hardening the media stack
May 5, 2016
Posted by Dan Austin and Jeff Vander Stoep, Android Security team
[Cross-posted from the
Android Developers Blog
]
To help make Android more secure, we encourage and
reward
researchers who discover vulnerabilities. In 2015, a series of bugs in mediaserver’s libstagefright were disclosed to Google. We released updates for these issues with our August and September 2015
security bulletins
.
In addition to addressing issues on a monthly basis, we’ve also been working on new security features designed to enhance the existing security model and provide additional defense in-depth. These defense measures attempt to achieve two goals:
Prevention
: Stop bugs from becoming vulnerabilities
Containment
: Protect the system by de-privileging and isolating components that handle untrusted content
Prevention
Most of the vulnerabilities found in libstagefright were heap overflows resulting from unsigned
integer overflows
. A number of integer overflows in libstagefright allowed an attacker to allocate a buffer with less space than necessary for the incoming data, resulting in a buffer overflow in the heap.
The result of an unsigned integer overflow is well defined, but the ensuing behavior could be unexpected or unsafe. In contrast, signed integer overflows are considered undefined behavior in C/C++, which means the result of an overflow is not guaranteed, and the compiler author may choose the resulting behavior—typically what is fastest or simplest. We have added compiler changes that are designed to provide safer defaults for both signed and unsigned integer overflows.
The UndefinedBehaviorSanitizer (
UBSan
) is part of the LLVM/Clang compiler toolchain that detects undefined or unintended behavior. UBSan can check for multiple types of undefined and unsafe behavior, including signed and unsigned integer overflow. These checks add code to the resulting executable, testing for integer overflow conditions during runtime. For example, figure 1 shows source code for the
parseChunk
function in the
MPEG4Extractor
component of libstagefright after the original researcher-supplied patch was applied. The modification, which is contained in the black box below, appears to prevent integer overflows from occurring. Unfortunately, while
SIZE_MAX
and
size
are 32-bit values,
chunk_size
is a 64-bit value, resulting in an incomplete check and the potential for integer overflow. In the line within the red box, the addition of
size
and
chunk_size
may result in an integer overflow and creation of buffer smaller than
size
elements. The subsequent
memcpy
could then lead to exploitable memory corruption, as
size
+
chunk_size
could be less than
size
, which is highlighted in the blue box. The mechanics of a potential exploit vector for this vulnerability are explained in more detail by
Project Zero
.
Figure 1.
Source code demonstrating a subtle unsigned integer overflow.
Figure 2 compares assembly generated from the code segment above with a second version compiled with integer sanitization enabled. The add operation that results in the integer overflow is contained in the red box.
In the unsanitized version,
size
(
r6
) and
chunk_size
(
r7
) are added together, potentially resulting in
r0
overflowing and being less than
size
. Then,
buffer
is allocated with the
size
specified in
r0
, and
size
bytes are copied to it. If
r0
is less than
r6
, this results in memory corruption.
In the sanitized version,
size
(
r7
) and
chunk_size
(
r5
) are added together with the result stored in
r0
. Later,
r0
is checked against
r7
, if
r0
is less than
r7
, as indicated by the
CC
condition code,
r3
is set to 1. If
r3
is 1, and the carry bit was set, then an integer overflow occurred, and an abort is triggered, preventing memory corruption.
Note that the incomplete check provided in the patch was not included in figure 2. The overflow occurs in the
buffer
allocation’s
add
operation. This addition triggers an integer sanitization check, which turns this exploitable flaw into a harmless abort.
Figure 2.
Comparing unsanitized and sanitized compiler output.
While the integer sanitizers were originally intended as code hygiene tools, they effectively prevent the majority of reported libstagefright vulnerabilities. Turning on the integer overflow checks was just the first step. Preventing the runtime abort by finding and fixing integer overflows, most of which are not exploitable, represented a large effort by Android's media team. Most of the discovered overflows were fixed and those that remain (mostly for performance reasons) were verified and marked as safe to prevent the runtime abort.
In Android N, signed and unsigned integer overflow detection is enabled on the entire media stack, including libstagefright. This makes it harder to exploit integer overflows, and also helps to prevent future additions to Android from introducing new integer overflow bugs.
Containment
For Android M and earlier, the mediaserver process in Android was responsible for most media-related tasks. This meant that it required access to all permissions needed by those responsibilities and, although mediaserver ran in its own sandbox, it still had access to a lot of resources and capabilities. This is why the libstagefright bugs from 2015 were significant—mediaserver could access several important resources on an Android device including camera, microphone, graphics, phone, Bluetooth, and internet.
A root cause analysis showed that the libstagefright bugs primarily occurred in code responsible for parsing file formats and media codecs. This is not surprising—parsing complex file formats and codecs while trying to optimize for speed is hard, and the large number of edge cases makes such code susceptible to both accidental and malicious malformed inputs.
However, media parsers do not require access to most of the privileged permissions held by mediaserver. Because of this, the media team re-architected mediaserver in Android N to better adhere to the principle of least privilege. Figure 3 illustrates how the monolithic mediaserver and its permissions have been divided, using the following heuristics:
parsing code moved into unprivileged sandboxes that have few or no permissions
components that require sensitive permissions moved into separate sandboxes that only grant access to the specific resources the component needs. For example, only the cameraserver may access the camera, only the audioserver may access Bluetooth, and only the drmserver may access DRM resources.
Figure 3
. How mediaserver and its permissions have been divided in Android N.
Comparing the potential impact of the libstagefright bugs on Android N and older versions demonstrates the value of this strategy. Gaining code execution in libstagefright previously granted access to all the permissions and resources available to the monolithic mediaserver process including graphics driver, camera driver, or sockets, which present a rich kernel attack surface.
In Android N, libstagefright runs within the mediacodec sandbox with access to very few permissions. Access to camera, microphone, photos, phone, Bluetooth, and internet as well as dynamic code loading are disallowed by
SELinux
. Interaction with the kernel is further restricted by
seccomp
. This means that compromising libstagefright would grant the attacker access to significantly fewer permissions and also mitigates privilege escalation by reducing the attack surface exposed by the kernel.
Conclusion
The media hardening project is an ongoing effort focused on moving functionality into less privileged sandboxes and further reducing the permissions granted to those sandboxes. While the techniques discussed here were applied to the Android media framework, they are suitable across the Android codebase. These hardening techniques—and others—are being actively applied to additional components within Android. As always, we appreciate feedback on our work and welcome suggestions for how we can improve Android. Contact us at
security@android.com
.
Bringing HTTPS to all blogspot domain blogs
May 3, 2016
Posted by Milinda Perera, Software Engineer, Security
HTTPS is fundamental to internet security; it protects the integrity and confidentiality of data sent between websites and visitors' browsers. Last September, we
began
rolling out HTTPS support for blogspot domain blogs so you could try it out. Today, we’re launching another milestone: an HTTPS version for every blogspot domain blog. With this change, visitors can access any blogspot domain blog over an encrypted channel.
The HTTPS indicator in the Chrome browser
As part of this launch, we're removing the HTTPS Availability setting. Even if you did not previously turn on this setting, your blogs will have an HTTPS version enabled.
We’re also adding a
new setting called HTTPS Redirect
that allows you to opt-in to redirect HTTP requests to HTTPS. While all blogspot blogs will have an HTTPS version enabled, if you turn on this new setting, all visitors will be redirected to the HTTPS version of your blog at
https
://<your-blog>.blogspot.com even if they go to
http
://<your-blog>.blogspot.com. If you choose to turn off this setting, visitors will have two options for viewing your blog: the unencrypted version at
http
://<your-blog>.blogspot.com or the encrypted version at
https
://<your-blog>.blogspot.com.
The new HTTPS Redirect setting in the Blogger dashboard
Please be aware that
mixed content
may cause some of your blog's functionality not to work in the HTTPS version. Mixed content is often caused by incompatible templates, gadgets, or post content. While we're proactively fixing most of these errors, some of them can only be fixed by you, the blog authors. To help
spot and fix
these errors, we recently
released
a mixed content warning tool that alerts you to possible mixed content issues in your posts, and gives you the option to fix them automatically before saving.
Existing links and bookmarks to your blogs are not affected by this launch, and will continue to work. Please note that blogs on custom domains will not yet have HTTPS support.
This update expands Google's
HTTPS Everywhere
mission to all blogspot domain blogs. We appreciate your
feedback
and will use it to make future improvements.
Labels
#sharethemicincyber
#supplychain #security #opensource
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome enterprise
chrome security
connected devices
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
hacking
interoperability
iot security
kubernetes
linux kernel
memory safety
Open Source
pha family highlights
pixel
privacy
private compute core
Rowhammer
rust
Security
security rewards program
sigstore
spyware
supply chain
targeted spyware
tensor
Titan M2
VDP
vulnerabilities
workshop
Archive
2024
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2023
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2022
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Aug
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
2010
Nov
Oct
Sep
Aug
Jul
May
Apr
Mar
2009
Nov
Oct
Aug
Jul
Jun
Mar
2008
Dec
Nov
Oct
Aug
Jul
May
Feb
2007
Nov
Oct
Sep
Jul
Jun
May
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow