Archives : August-2017

Posted by Hoi Lam, Lead Developer
Advocate, Android Wear

Strava – a standalone wear app available to both Android and iOS users

Android Wear 2.0 represents the the latest evolution of the Android Wear
platform. It introduced the concept of standalone
apps
that can connect to the network directly and work independently of a
smartphone. This is critical to providing apps not only to our Android users,
but also iOS users – which is increasingly important as we continue to expand
our diverse ecosystem of watches and users. In addition, Wear 2.0 brought
multi-APK support to Wear apps, which reduces the APK size of your phone apps,
and makes it possible for iOS users to experience your Wear apps.

Today, we are announcing that multi-APKs will also work for Android Wear 1.0
watches, so you can now reach all of your users without needing to bundle your
Wear app within your phone app’s APK. Additionally, the Google Play Store policy
will change to promote the use of multi-APKs and standalone apps. This covers
all types of apps that are designed to run on the watch, including watch faces,
complication data providers as well as launchable apps.

Policy change

The policy change will be effective from the 18th of January, 2018. At this
time, the following apps will lose the “Enhanced for Android Wear” badge in the
Google Play Store and will not be eligible to be listed in the top charts in the
Play Store for Android Wear:

  • Mobile apps that support Wear notification enhancements but do not have a
    separate Wear app.
  • Wear apps that are bundled with mobile apps instead of using
    multi-APK.

Since multi-APK is now supported by devices running Wear 1.0 and 2.0, developers
embedding their Wear app APKs in phone APKs should unbundle their Wear APK
and upload
it to the Play Store as a multi-APK
. This will allow them to continue to
qualify for the “Enhanced for Android Wear” badge as well as be eligible to
appear in the Android Wear top charts. The two APKs can continue to share the
same package name.

In addition to providing top app charts, we periodically put together curated
featured collections. To be eligible for selection for these collections,
developers will need to make their Wear apps function independently from the
phone, as a standalone app. These apps will need to work on watches that are
paired with both iOS and Android phones.

What are standalone apps?

Standalone
apps
are Wear apps that do not require a phone app to run. The app either
does not require network access or can access the network directly without the
phone app – something that is supported by Android Wear 2.0.

To mark your app as standalone, put the following meta-data tag in the
AndroidManifest.xml:

<application>
...
  <meta-data
    android:name="com.google.android.wearable.standalone"
    android:value="true" />
...
</application>

In some rare cases, the user experience may be enhanced by the syncing of data
between the phone and watch. For example, a cycling app can use the watch to
display the current pace, and measure the user’s heart rate, while displaying a
map on the phone. In this scenario, we recommend that developers ensure that
their Wear apps function without a phone and treat the phone experience as
optional as far as the Wear apps are concerned. In these cases, a Wear app is
still considered standalone and should be marked as such in its
AndroidManifest.xml file.

Wear what you want

From the beginning, Android Wear has been about wear what you want — the
styles, watches, and apps you want to wear. This latest policy change lets you
highlight your Android Wear apps, giving users even more choice about what apps
they want on their watches.

Read more

Posted by Sami Tolvanen, Senior Software Engineer, Android Security

The hardening of Android’s userspace has increasingly made the underlying Linux
kernel a more attractive target to attackers. As a result, more than a third of
Android security bugs were found in the kernel last year. In Android 8.0 (Oreo),
significant effort has gone into hardening the kernel to reduce the number and
impact of security bugs.

Android
Nougat
worked to protect the kernel by isolating it from userspace processes
with the addition of SELinux ioctl filtering and requiring seccomp-bpf support,
which allows apps to filter access to available system calls when processing
untrusted input. Android 8.0 focuses on kernel self-protection with four
security-hardening features backported from upstream Linux to all Android
kernels supported in devices that first ship with this release.

Hardened usercopy

Usercopy functions are used by the kernel to transfer data from user space to
kernel space memory and back again. Since 2014, missing or invalid bounds
checking has caused about 45% of Android’s kernel vulnerabilities. Hardened usercopy adds bounds
checking to usercopy functions, which helps developers spot misuse and fix bugs
in their code. Also, if obscure driver bugs slip through, hardening these
functions prevents the exploitation of such bugs.

This feature was
introduced
in the upstream kernel version 4.8, and we have backported it to
Android kernels 3.18 and above.

int buggy_driver_function(void __user *src, size_t size)
{
    /* potential size_t overflow (don’t do this) */
    u8 *buf = kmalloc(size * N, GPF_KERNEL);
    …
    /* results in buf smaller than size, and a heap overflow */
    if (copy_from_user(buf, src, size))
    return -EFAULT;

    /* never reached with CONFIG_HARDENED_USERCOPY=y */
}

An example of a security issue that hardened usercopy prevents.

Privileged Access Never (PAN) emulation

While hardened usercopy functions help find and mitigate security issues, they
can only help if developers actually use them. Currently, all kernel code,
including drivers, can access user space memory directly, which can lead to
various security issues.

To mitigate this, CPU vendors have introduced features such as Supervisor Mode
Access Prevention (SMAP) in x86 and Privileged Access Never (PAN) in ARM v8.1.
These features prevent the kernel from accessing user space directly and ensure
developers go through usercopy functions. Unfortunately, these hardware features
are not yet widely available in devices that most Android users have today.

Upstream Linux introduced software emulation for PAN in kernel version 4.3
for ARM
and 4.10 in ARM64. We
have backported both features to Android kernels starting from 3.18.

Together with hardened usercopy, PAN emulation has helped find and fix bugs in
four kernel drivers in Pixel devices.

int buggy_driver_copy_data(struct mydata *src, void __user *ptr)
{
    /* failure to keep track of user space pointers */
    struct mydata *dst = (struct mydata *)ptr;
    …
    /* read/write from/to an arbitrary user space memory location */
    dst->field = … ;    /* use copy_(from|to)_user instead! */
    …
    /* never reached with PAN (emulation) or SMAP */
}

An example of a security issue that PAN emulation mitigates.

Kernel Address Space Layout Randomization (KASLR)

Android has included support for Address Space Layout Randomization (ASLR) for
years. Randomizing memory layout makes code reuse attacks probabilistic and
therefore more difficult for an attacker to exploit, especially remotely.
Android 8.0 brings this feature to the kernel. While Linux has supported KASLR on x86 since version 3.14, KASLR for ARM64 has only been
available upstream since Linux 4.6. Android 8.0 makes KASLR available in Android
kernels 4.4 and newer.

KASLR helps mitigate kernel vulnerabilities by randomizing the location where
kernel code is loaded on each boot. On ARM64, for example, it adds 13–25 bits of
entropy depending on the memory configuration of the device, which makes code
reuse attacks more difficult.

Post-init read-only memory

The final hardening feature extends existing memory protections in the kernel by
creating a memory region that’s marked read-only after the kernel has been
initialized. This makes it possible for developers to improve protection on data
that needs to be writable during initialization, but shouldn’t be modified after
that. Having less writable memory reduces the internal attack surface of the
kernel, making exploitation harder.

Post-init read-only memory was
introduced in upstream kernel version 4.6 and we have backported it to Android
kernels 3.18 and newer. While we have applied these protections to some data
structures in the core kernel, this feature is extremely useful for developers
working on kernel drivers.

Conclusion

Android Oreo includes mitigations for the most common source of security bugs in
the kernel. This is especially relevant because 85% of kernel security bugs in
Android have been in vendor drivers that tend to get much less scrutiny. These
updates make it easier for driver developers to discover common bugs during
development, stopping them before they can reach end user devices.