Posted by Chad Brubaker, Android Security team
In Android Nougat, we’ve changed how Android handles trusted certificate authorities (CAs) to provide safer defaults for secure app traffic. Most apps and users should not be affected by these changes or need to take any action. The changes include:
For more details on these changes and what to do if you’re affected by them, read on.
Apps have always been able customize which certificate authorities they trust. However, we saw apps making mistakes due to the complexities of the Java TLS APIs. To address this we improved the APIs for customizing trust.
Protection of all application data is a key goal of the Android application sandbox. Android Nougat changes how applications interact with user- and admin-supplied CAs. By default, apps that target API level 24 will—by design—not honor such CAs unless the app explicitly opts in. This safe-by-default setting reduces application attack surface and encourages consistent handling of network and file-based application data.
Customizing the CAs your app trusts on Android Nougat is easy using the Network Security Config. Trust can be specified across the whole app or only for connections to certain domains, as needed. Below are some examples for trusting a custom or user-added CA, in addition to the system CAs. For more examples and details, see the full documentation.
To allow your app to trust custom CAs only for local debugging, include something like this in your Network Security Config. The CAs will only be trusted while your app is marked as debuggable.
<network-security-config> <debug-overrides> <trust-anchors> <!-- Trust user added CAs while debuggable only --> <certificates src="user" /> </trust-anchors> </domain-config> </network-security-config>
To allow your app to trust custom CAs for a specific domain, include something like this in your Network Security Config.
<network-security-config> <domain-config> <domain includeSubdomains="true">internal.example.com</domain> <trust-anchors> <!-- Only trust the CAs included with the app for connections to internal.example.com --> <certificates src="@raw/cas" /> </trust-anchors> </domain-config> </network-security-config>
To allow your app to trust user-added CAs for multiple domains, include something like this in your Network Security Config.
<network-security-config> <domain-config> <domain includeSubdomains="true">userCaDomain.com</domain> <domain includeSubdomains="true">otherUserCaDomain.com</domain> <trust-anchors> <!-- Trust preinstalled CAs --> <certificates src="system" /> <!-- Additionally trust user added CAs --> <certificates src="user" /> </trust-anchors> </domain-config> </network-security-config>
To allow your app to trust user-added CAs for all domains, except for those specified, include something like this in your Network Security Config.
<network-security-config> <base-config> <trust-anchors> <!-- Trust preinstalled CAs --> <certificates src="system" /> <!-- Additionally trust user added CAs --> <certificates src="user" /> </trust-anchors> </base-config> <domain-config> <domain includeSubdomains="true">sensitive.example.com</domain> <trust-anchors> <!-- Only allow sensitive content to be exchanged with the real server and not any user or admin configured MiTMs --> <certificates src="system" /> <trust-anchors> </domain-config> </network-security-config>
To allow your app to trust user-added CAs for all secure connections, add this in your Network Security Config.
<network-security-config> <base-config> <trust-anchors> <!-- Trust preinstalled CAs --> <certificates src="system" /> <!-- Additionally trust user added CAs --> <certificates src="user" /> </trust-anchors> </base-config> </network-security-config>
To provide a more consistent and more secure experience across the Android ecosystem, beginning with Android Nougat, compatible devices trust only the standardized system CAs maintained in AOSP.
Previously, the set of preinstalled CAs bundled with the system could vary from device to device. This could lead to compatibility issues when some devices did not include CAs that apps needed for connections as well as potential security issues if CAs that did not meet our security requirements were included on some devices.
First, be sure that your CA needs to be included in the system. The preinstalled CAs are only for CAs that meet our security requirements because they affect the secure connections of most apps on the device. If you need to add a CA for connecting to hosts that use that CA, you should instead customize your apps and services that connect to those hosts. For more information, see the Customizing trusted CAs section above.
If you operate a CA that you believe should be included in Android, first complete the Mozilla CA Inclusion Process and then file a feature request against Android to have the CA added to the standardized set of system CAs.
Posted by Dimitry Ivanov & Elliott Hughes, Software Engineers
As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code can link against at runtime. As a result, if your app uses any private symbols from platform libraries, you will need to update it to either use the public NDK APIs or to include its own copy of those libraries. Some libraries are public: the NDK exposes libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are private, and Android N only allows access to them for platform HALs, system daemons, and the like. If you aren’t sure whether your app uses private libraries, you can immediately check it for warnings on the N Developer Preview.
We’re making this change because it’s painful for users when their apps stop working after a platform update. Whether they blame the app developer or the platform, everybody loses. Users should have a consistent app experience across updates, and developers shouldn’t have to make emergency app updates to handle platform changes. For that reason, we recommend against using private C/C++ symbols. Private symbols aren’t tested as part of the Compatibility Test Suite (CTS) that all Android devices must pass. They may not exist, or they may behave differently. This makes apps that use them more likely to fail on specific devices, or on future releases — as many developers found when Android 6.0 Marshmallow switched from OpenSSL to BoringSSL.
You may be surprised that there’s no STL in the list of NDK libraries. The three STL implementations included in the NDK — the LLVM libc++, the GNU STL, and libstlport — are intended to be bundled with your app, either by statically linking into your library, or by inclusion as a separate shared library. In the past, some developers have assumed that they didn’t need to package the library because the OS itself had a copy. This assumption is incorrect: a particular STL implementation may disappear (as was the case with stlport, which was removed in Marshmallow), may never have been available (as is the case with the GNU STL), or it may change in ABI incompatible ways (as is the case with the LLVM libc++).
In order to reduce the user impact of this transition, we’ve identified a set of libraries that see significant use from Google Play’s most-installed apps, and that are feasible for us to support in the short term (including libandroid_runtime.so, libcutils.so, libcrypto.so, and libssl.so). For legacy code in N, we will temporarily support these libraries in order to give you more time to transition. Note that we don't intend to continue this support in any future Android platform release, so if you see a warning that means your code will not work in a future release — please fix it now!
Table 1. What to expect if your app is linking against private native libraries.
Please test your app during the N Previews.
targetSdkVersion
Test your apps on the Developer Preview — if you see a toast like this one, your app is accessing private native APIs. Please fix your code soon!
Here’s some example logcat output from an app that hasn’t bumped its target SDK version (and so the restriction isn’t fully enforced because this is only the developer preview):
03-21 17:07:51.502 31234 31234 W linker : library "libandroid_runtime.so" ("/system/lib/libandroid_runtime.so") needed or dlopened by "/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible for the namespace "classloader-namespace" - the access is temporarily granted as a workaround for http://b/26394120
This is telling you that your library “libapplib.so” refers to the library “libandroid_runtime.so”, which is a private library.
When Android N ships, or if you set your target SDK version to N now, you’ll see something like this if you try to use System.loadLibrary from Java:
java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so" ("/system/lib/libcutils.so") needed or dlopened by "/system/lib/libnativeloader.so" is not accessible for the namespace "classloader-namespace" at java.lang.Runtime.loadLibrary0(Runtime.java:977) at java.lang.System.loadLibrary(System.java:1602)
If you’re using dlopen(3) from C/C++ you’ll get a NULL return and dlerror(3) will return the same “dlopen failed...” string as shown above.
For more information about how to check if your app is using private symbols, see the FAQ on developer.android.com.
Posted by Dave Burke, VP of Engineering
As we put the finishing touches on the next release of Android, which will begin to roll out to consumers later this summer, we’re releasing the 4th Developer Preview of Android N, including the Android N final SDK. And thanks to your continued feedback over the last three releases, all of the APIs are now final as well. If you’ve already enrolled your device in the Android Beta Program, (available at android.com/beta) you will receive an update to this Developer Preview shortly.
The final SDK for Android N is now available for download through the SDK Manager in Android Studio. It gives you everything you need to develop and test against the official APIs in the Android N platform. Once you’ve installed the final SDK, you can update your project’s compileSdkVersion to API 24 to develop with the Android N APIs and build and test on the new platform, for new features such as Multi-window support, direct-reply notifications, and others. We also recommend updating your app’s targetSdkVersion to API 24 to opt-in and test your app with Android N specific behavior changes. For details on how to setup your app with the final SDK, see Set up the Preview. For details on API level 24 check out the API diffs and the updated API reference, now hosted online.
compileSdkVersion
Along with the Android N final SDK, we’ve also updated the Android Support Library to 24.0.0. This allows you to use multi-window and picture-in-picture callbacks, new notification features, methods for supporting Direct Boot, and new MediaBrowser APIs in a backward compatible manner.
Now that you have a final set of APIs, you can publish updates compiling with, and optionally targeting, API 24 to Google Play. You can now publish app updates that use API 24 to your alpha, beta, or even production channels in the Google Play Developer Console. In this way, you can test your app’s backward-compatibility and push updates to users whose devices are running Developer Preview 4.
To make sure that your updated app runs well on Android N, as well as older versions, a common strategy is to use Google Play’s beta testing feature to get early feedback from a small group of users -- including developer preview users — and then do a staged rollout as you release the updated app to all users.
Developer Preview 4 includes updated system images for all supported Preview devices as well as for the Android emulator. If you are already enrolled in the Android Beta program, your devices will get the Developer Preview 4 update right away, no action is needed on your part. If you aren’t yet enrolled in Android Beta, the easiest way to get started is by visiting android.com/beta and opt-in your eligible Android phone or tablet -- you’ll soon receive this (and later) preview updates over-the-air. As always, you can also download and flash this update manually. The N Developer Preview is available for Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, and Pixel C devices, as well as General Mobile 4G [Android One] devices and the Sony Xperia Z3.
Thanks so much for all of your feedback so far. Please continue to share feedback or requests either in the N Developer Preview issue tracker, N Preview Developer community, or Android Beta community as we work towards the consumer release later this summer. We’re looking forward to seeing your apps on Android N!
Posted by Sergio Giro, software engineer
If your Android app derives keys using the SHA1PRNG algorithm from the Crypto provider, you must start using a real key derivation function and possibly re-encrypt your data.
The Java Cryptography Architecture allows developers to create an instance of a class like a cipher, or a pseudo-random number generator, using calls like:
SomeClass.getInstance("SomeAlgorithm", "SomeProvider");
Or simply:
SomeClass.getInstance("SomeAlgorithm");
For instance,
Cipher.getInstance(“AES/CBC/PKCS5PADDING”); SecureRandom.getInstance(“SHA1PRNG”);
On Android, we don’t recommend specifying the provider. In general, any call to the Java Cryptography Extension (JCE) APIs specifying a provider should only be done if the provider is included in the application or if the application is able to deal with a possible ProviderNotFoundException.
Unfortunately, many apps depend on the now removed “Crypto” provider for an anti-pattern of key derivation.
This provider only provided an implementation of the algorithm “SHA1PRNG” for instances of SecureRandom. The problem is that the SHA1PRNG algorithm is not cryptographically strong. For readers interested in the details, On statistical distance based testing of pseudo random sequences and experiments with PHP and Debian OpenSSL,Section 8.1, by Yongge Want and Tony Nicol, states that the “random” sequence, considered in binary form, is biased towards returning 0s, and that the bias worsens depending on the seed.
As a result, in Android N we are deprecating the implementation of the SHA1PRNG algorithm and the Crypto provider altogether. We’d previously covered the issues with using SecureRandom for key derivation a few years ago in Using Cryptography to Store Credentials Safely. However, given its continued use, we will revisit it here.
A common but incorrect usage of this provider was to derive keys for encryption by using a password as a seed. The implementation of SHA1PRNG had a bug that made it deterministic if setSeed() was called before obtaining output. This bug was used to derive a key by supplying a password as a seed, and then using the "random" output bytes for the key (where “random” in this sentence means “predictable and cryptographically weak”). Such a key could then be used to encrypt and decrypt data.
In the following, we explain how to derive keys correctly, and how to decrypt data that has been encrypted using an insecure key. There’s also a full example, including a helper class to use the deprecated SHA1PRNG functionality, with the sole purpose of decrypting data that would be otherwise unavailable.
Keys can be derived in the following way:
SecretKey key = new SecretKeySpec(keyBytes, "AES");
/* User types in their password: */ String password = "password"; /* Store these things on disk used to derive key later: */ int iterationCount = 1000; int saltLength = 32; // bytes; should be the same size as the output (256 / 8 = 32) int keyLength = 256; // 256-bits for AES-256, 128-bits for AES-128, etc byte[] salt; // Should be of saltLength /* When first creating the key, obtain a salt with this: */ SecureRandom random = new SecureRandom(); byte[] salt = new byte[saltLength]; random.nextBytes(salt); /* Use this to derive the key from the password: */ KeySpec keySpec = new PBEKeySpec(password.toCharArray(), salt, iterationCount, keyLength); SecretKeyFactory keyFactory = SecretKeyFactory .getInstance("PBKDF2WithHmacSHA1"); byte[] keyBytes = keyFactory.generateSecret(keySpec).getEncoded(); SecretKey key = new SecretKeySpec(keyBytes, "AES");
That's it. You should not need anything else.
To make transitioning data easier, we covered the case of developers that have data encrypted with an insecure key, which is derived from a password every time. You can use the helper class InsecureSHA1PRNGKeyDerivator in the example app to derive the key.
InsecureSHA1PRNGKeyDerivator
private static SecretKey deriveKeyInsecurely(String password, int keySizeInBytes) { byte[] passwordBytes = password.getBytes(StandardCharsets.US_ASCII); return new SecretKeySpec( InsecureSHA1PRNGKeyDerivator.deriveInsecureKey( passwordBytes, keySizeInBytes), "AES"); }
You can then re-encrypt your data with a securely derived key as explained above, and live a happy life ever after.
Note 1: as a temporary measure to keep apps working, we decided to still create the instance for apps targeting SDK version 23, the SDK version for Marshmallow, or less. Please don't rely on the presence of the Crypto provider in the Android SDK, our plan is to delete it completely in the future.
Note 2: Because many parts of the system assume the existence of a SHA1PRNG algorithm, when an instance of SHA1PRNG is requested and the provider is not specified we return an instance of OpenSSLRandom, which is a strong source of random numbers derived from OpenSSL.
Posted by Ian Lake, Developer Advocate
Android notifications are often a make-or-break interaction between your Android app and users. To provide a better user experience, notifications on Android N have received a visual refresh, improved support for custom views, and expanded functionality in the forms of Direct Reply, a new MessagingStyle, and bundled notifications.
MessagingStyle
The first and most obvious change is that the default look and feel of notifications has significantly changed. Many of the fields that were spread around the notifications have been collapsed into a new header row with your app’s icon and name anchoring the notification. This change ensured that the title, text, and large icon are given the most amount of space possible and, as a result, notifications are generally slightly larger now and easier to read.
Given the single header row, it is more important than ever that the information there is useful. When you target Android N, by default the time will be hidden - if you have a time critical notification such as a messaging app, you can re-enable it with setShowWhen(true). In addition, the subtext now supersedes the role of content info and number: number is never shown on Android N devices and only if you target a previous version of Android and don’t include a subtext will content info appear. In all cases, ensure that the subtext is relevant and useful - don’t add an account email address as your subtext if the user only has one account, for example.
setShowWhen(true)
Notification actions have also received a redesign and are now in a visually separate bar below the notification.
You’ll note that the icons are not present in the new notifications; instead more room is provided for the labels themselves in the constrained space of the notification shade. However, the notification action icons are still required and continue to be used on older versions of Android and on devices such as Android Wear.
If you’ve been building your notification with NotificationCompat.Builder and the standard styles available to you there, you’ll get the new look and feel by default with no code changes required.
NotificationCompat.Builder
If you’re instead building your notification from custom RemoteViews, adapting to any new style has been challenging. With the new header, expanding behavior, actions, and large icon positioning as separate elements from the main text+title of the notification, we’ve introduced a new DecoratedCustomViewStyle and DecoratedMediaCustomViewStyle to provide all of these elements, allowing you to focus only on the content portion with the new setCustomContentView() method.
RemoteViews
DecoratedCustomViewStyle
DecoratedMediaCustomViewStyle
setCustomContentView()
This also ensures that future look and feel changes should be significantly easier to adapt to as these styles will be updated alongside the platform with no code changes needed on the app side.
While notification actions have already been able to launch an Activity or do background work with a Service or BroadcastReceiver, Direct Reply allows you to build an action that directly receives text input inline with the notification actions.
Activity
Service
BroadcastReceiver
Direct Reply uses the same RemoteInput API - originally introduced for Android Wear - to mark an Action as being able to directly receive input from the user.
RemoteInput
Action
The RemoteInput itself contains information like the key which will be used to later retrieve the input and the hint text which is displayed before the user starts typing.
// Where should direct replies be put in the intent bundle (can be any string) private static final String KEY_TEXT_REPLY = "key_text_reply"; // Create the RemoteInput specifying this key String replyLabel = getString(R.string.reply_label); RemoteInput remoteInput = new RemoteInput.Builder(KEY_TEXT_REPLY) .setLabel(replyLabel) .build();
Once you’ve constructed the RemoteInput, it can be attached to your Action via the aptly named addRemoteInput() method. You might consider also calling setAllowGeneratedReplies(true) to enable Android Wear 2.0 to generate Smart Reply choices when available and make it easier for users to quickly respond.
addRemoteInput()
setAllowGeneratedReplies(true)
// Add to your action, enabling Direct Reply for it NotificationCompat.Action action = new NotificationCompat.Action.Builder(R.drawable.reply, replyLabel, pendingIntent) .addRemoteInput(remoteInput) .setAllowGeneratedReplies(true) .build();
Keep in mind that the pendingIntent being passed into your Action should be an Activity on Marshmallow and lower devices that don’t support Direct Reply (as you’ll want to dismiss the lock screen, start an Activity, and focus the input field to have the user type their reply) and should be a Service (if you need to do work on a separate thread) or BroadcastReceiver (which runs on the UI thread) on Android N devices so as the process the text input in the background even from the lock screen. (There is a separate user control to enable/disable Direct Reply from a locked device in the system settings.)
pendingIntent
Extracting the text input in your Service/BroadcastReceiver is then possible with the help of the RemoteInput.getResultsFromIntent() method:
RemoteInput.getResultsFromIntent()
private CharSequence getMessageText(Intent intent) { Bundle remoteInput = RemoteInput.getResultsFromIntent(intent); if (remoteInput != null) { return remoteInput.getCharSequence(KEY_TEXT_REPLY); } return null; }
After you’ve processed the text, you must update the notification by calling notify() with the same id and tag (if used). This is the trigger which hides the Direct Reply UI and should be used as a technique to confirm to the user that their reply was received and processed correctly.
notify()
id
tag
For most templates, this should involve using the new setRemoteInputHistory() method which appends the reply to the bottom of the notification. Additional replies should be appended to the history until the main content is updated (such as the other person replying).
setRemoteInputHistory()
However, if you’re building a messaging app and expect back and forth conversations, you should use MessagingStyle and append the additional message to it.
We’ve optimized the experience for displaying an ongoing conversation and using Direct Reply with the new MessagingStyle.
This style provides built-in formatting for multiple messages added via the addMessage() method. Each message supports passing in the text itself, a timestamp, and the sender of the message (making it easy to support group conversations).
addMessage()
builder.setStyle(new NotificationCompat.MessagingStyle("Me") .setConversationTitle("Team lunch") .addMessage("Hi", timestampMillis1, null) // Pass in null for user. .addMessage("What's up?", timestampMillis2, "Coworker") .addMessage("Not much", timestampMillis3, null) .addMessage("How about lunch?", timestampMillis4, "Coworker"));
You’ll note that this style has first-class support for specifically denoting messages from the user and filling in their name (in this case with “Me”) and setting an optional conversation title. While this can be done manually with a BigTextStyle, by using this style Android Wear 2.0 users will get immediate inline responses without kicking them out of the expanded notification view, making for a seamless experience without needing to build a full Wear app.
BigTextStyle
Once you’ve built a great notification by using the new visual designs, Direct Reply, MessagingStyle, and all of our previous best practices, it is important to think about the overall notification experience, particularly if you post multiple notifications (say, one per ongoing conversation or per new email thread).
If you’ve built stacking notifications for Android Wear, the API used here is exactly the same. Simply add setGroup() to each individual notification to bundle those notifications together. You’re not limited to one group, so bundle notifications appropriately. For an email app, you might consider one bundle per account for instance.
setGroup()
It is important to also create a summary notification. This summary notification, denoted by setGroupSummary(true), is the only notification that appears on Marshmallow and lower devices and should (you guessed it) summarize all of the individual notifications. This is an opportune time to use the InboxStyle, although using it is not a requirement. On Android N and higher devices, some information (such as the subtext, content intent, and delete intent) is extracted from the summary notification to produce the collapsed notification for the bundled notifications so you should continue to generate a summary notification on all API levels.
setGroupSummary(true)
InboxStyle
To improve the overall user experience on Android N devices, posting 4 or more notifications without a group will cause those notifications to be automatically bundled.
Notifications on Android have been a constant area of progressive enhancement. From the single tap targets of the Gingerbread era to expandable notifications, actions, MediaStyle, and now features such as Direct Reply and bundled notifications, notifications play an important part of the overall user experience on Android.
With many new tools to use (and NotificationCompat to help with backward compatibility), I’m excited to see how you use them to #BuildBetterApps
NotificationCompat
Follow the Android Development Patterns Collection for more!
minimalHeight
minimalWidth
Posted by Dan Austin and Jeff Vander Stoep, Android Security team
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:
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.
parseChunk
MPEG4Extractor
SIZE_MAX
size
chunk_size
memcpy
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.
r6
r7
r0
buffer
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.
r5
CC
r3
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.
add
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.
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:
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.
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.
Posted by Wojtek Kaliciński, Developer Advocate
Starting with Android N, a device that has been powered on can boot into a new mode called Direct Boot before the user has a chance to unlock it for the first time. In this mode, the operating system is fully operational, but access to private app data is limited and only apps that have been updated to be Direct Boot aware can run.
Not every app should run in Direct Boot mode, so before you start coding check if your app fits these common use cases:
Please note that this is not an exhaustive list and we look forward to seeing what other kinds of apps can benefit from Direct Boot.
In order to let your app run before the user unlocks the device, you have to explicitly mark components as being Direct Boot aware in the manifest:
<activity|provider|receiver|service ... android:directBootAware=”true”>
You can pick the subset of your app components that need to be Direct Boot aware, but if you are using a custom Application class, it is assumed to be Direct Boot aware if any component inside your app is marked as Direct Boot aware.
For apps that need to run as soon as the system starts in Direct Boot mode, there is a new Intent.ACTION_LOCKED_BOOT_COMPLETED broadcast. All apps will still receive Intent.ACTION_BOOT_COMPLETED after the user unlocks the device.
To support running apps before the user provides the credentials needed to unlock private app data, all Android N devices now provide two storage locations for data:
Components of your app that are marked as Direct Boot aware must rely on device protected storage for any data required for their operation during Direct Boot mode. They may still access credential protected storage after the user has unlocked the device.
To access device protected storage you need to create and use a secondary Context object for all file-related APIs:
Context deviceProtectedContext = context.createDeviceProtectedStorageContext(); deviceProtectedContext.openFileInput( ... )
When your app gets updated to a Direct Boot aware version, you might have previously saved Shared Preferences or databases that need to be migrated to device protected storage. You should use Context.moveSharedPreferencesFrom() and Context.moveDatabaseFrom() before accessing them to make sure the app continues to work properly even when data is backed up and restored from older versions or other devices.
You should think carefully about what you put in the device protected storage. This should be a minimum set of data that will let your app work during Direct Boot. For example, in a messaging app you could store an access token with a narrow scope that only has access to the number of new messages on your server. All sensitive, private information, like the full message history and a read/write access token, should still be saved in credential protected storage.
Another thing to remember is that during Direct Boot apps can only access other Direct Boot aware apps and components. If your app depends on external Services and Activities, make sure you gracefully handle the situation when they’re not available. Intent filters will by default match only components available in the current user state (locked / unlocked). There are two new flags for explicitly telling the Package Manager which components to enumerate: PackageManager.MATCH_DIRECT_BOOT_AWARE and PackageManager.MATCH_DIRECT_BOOT_UNAWARE.
Until devices with Android N that support Direct Boot out of the box are released, you can test your apps using Android N Developer Preview builds. On Nexus 5X and Nexus 6P, you can wipe all user data and enable full Direct Boot mode by using Settings > Developer options > Convert to file encryption. Alternatively, you can reboot into bootloader and issue the appropriate fastboot command:
$ adb reboot-bootloader $ fastboot --wipe-and-use-fbe
Warning: Both methods will perform a factory reset and delete all user data on your device.
Alternatively, you can use an emulated Direct Boot mode. To enable it, set a lock pattern on the device, choose "No thanks" if prompted for a secure start-up screen when setting a lock pattern, and then use the following adb shell commands to enable and disable emulation:
$ adb shell sm set-emulate-fbe true $ adb shell sm set-emulate-fbe false
Please note that using these commands will cause your device to reboot. You should only be using emulated Direct Boot mode on test devices, as it may cause data loss.
#BuildBetterApps
Posted by Jamal Eason, Product Manager, Android
With the launch Android N Developer Preview, we wanted to give you an easy and comprehensive way to build, test and validate your apps on the latest release with Android Studio. Built on the speed and feature enhancements of Android Studio 2.0, the stable release of Android Studio 2.1 includes updates to the IDE wizards, build system and Android Emulator so that you can try out new features and APIs of the developer preview including the new Jack compiler and Java 8 language support. In addition to support for the N Developer Preview, Android Studio 2.1 also includes performance improvements to Instant Run which leads to faster edit and deploy build speeds. If you are developing and validating your app with the N Developer Preview or want faster Instant Run speeds, you should download or update on the stable release channel to Android Studio 2.1.
Android Studio 2.1 includes the following new features:
N Developer Preview
On top of new features and APIs of the N Developer Preview, Android Studio 2.1 release includes support for the new Jack compiler and support for Java 8. With the Jack compiler, lambdas, method references, compile-time type annotations, intersection types and type inference are available on all versions of the Android platform. Default and static methods and repeatable annotations are available on Android N and higher. To use Java 8 language features when developing with the N Developer Preview, you need to use the Jack compiler. The New Project Wizard [File→ New→ Project] generates the correct configurations for projects targeting the N.
Getting started with development is as easy generating a new project or updating a few settings in your existing project. Once you are ready to test, you can create a fresh Android Virtual Device (AVD) and run your app on the N Developer Preview using the new Android Emulator.
Instant Run & General Build Performance Improvements
Instant Run and general build speed are now faster with two new features: incremental Java compilation and in-process dex.
In previous versions of Android Studio, a single line of Java code change will cause all the Java sources in the module to be recompiled. Now in Android Studio 2.1, incremental Java compilation is enabled by default to reduce compilation time by compiling only what is needed.
We are also speeding up build times by using in-process dex, which converts class files to dex files within the Gradle daemon process. This avoids the costly processing operation of creating separate dex processes. To use this feature, you will need to increase the amount of memory available to the Gradle daemon to at least 2GB (1 GB is the default). This feature will help speed up both incremental and full builds.
We’d appreciate your feedback as we continue to improve Instant Run and general build performance. We are going to keep working on making build times even faster in coming releases. Click here to learn even more about the build changes.
Update
If you are using a previous version of Android Studio, you can check for updates on the Stable channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). If you need a new copy of Android Studio, you can download it here.
Test and Validate Apps with N Developer Preview
After you update to or download Android Studio 2.1 and you want to test and develop your apps with the N Developer Preview, create a fresh Android Virtual Device (AVD) for the new Android emulator, and check out these additional setup instructions.
We appreciate any feedback on things you like, issues or features you would like to see. Connect with us -- the Android Studio development team -- on our Google+ page or on Twitter.
Posted by Alex Klyubin, Android Security team
When your app communicates with servers using cleartext network traffic, such as HTTP, the traffic risks being eavesdropped upon and tampered with by third parties. This may leak information about your users and open your app up to injection of unauthorized content or exploits. Ideally, your app should use secure traffic only, such as by using HTTPS instead of HTTP. Such traffic is protected against eavesdropping and tampering.
Many Android apps already use secure traffic only. However, some of them occasionally regress to cleartext traffic by accident. For example, an inadvertent change in one of the server components could make the server provide the app with HTTP URLs instead of HTTPS URLs. The app would then proceed to communicate in cleartext, without any user-visible symptoms. This situation may go unnoticed by the app’s developer and users.
Even if you believe your app is only using secure traffic, make sure to use the new mechanisms provided by Android Marshmallow (Android 6.0) to catch and prevent accidental regressions.
For apps which only use secure traffic, Android 6.0 Marshmallow (API Level 23) introduced two mechanisms to address regressions to cleartext traffic: (1) in production / installed base, block cleartext traffic, and (2) during development / QA, log or crash whenever non-TLS/SSL traffic is encountered. The following sections provide more information about these mechanisms.
To protect the installed base of your app against regressions to cleartext traffic, declare android:usesCleartextTraffic=”false” attribute on the application element in your app’s AndroidManifest.xml. This declares that the app is not supposed to use cleartext network traffic and makes the platform network stacks of Android Marshmallow block cleartext traffic in the app. For example, if your app accidentally attempts to sign in the user via a cleartext HTTP request, the request will be blocked and the user’s identity and password will not leak to the network.
You don’t have to set minSdkVersion or targetSdkVersion of your app to 23 (Android Marshmallow) to use android:usesCleartextTraffic. On older platforms, this attribute is simply ignored and thus has no effect.
Please note that WebView does not yet honor this feature.
And under certain circumstances cleartext traffic may still leave or enter the app. For example, Socket API ignores the cleartext policy because it does not know whether the data it transmits or receives can be classified as cleartext. Android platform HTTP stacks, on the other hand, honor the policy because they know whether traffic is cleartext.
Google AdMob is also built to honor this policy. When your app declares that it does not use cleartext traffic, only HTTPS-only ads should be served to the app.
Third-party network, ad, and analytics libraries are encouraged to add support for this policy. They can query the cleartext traffic policy via the NetworkSecurityPolicy class.
To spot cleartext traffic during development or QA, StrictMode API lets you modify your app to detect non-TLS/SSL traffic and then either log violations to system log or crash the app (see StrictMode.VmPolicy.Builder.detectCleartextNetwork()). This is a useful tool for identifying which bits of the app are using non-TLS/SSL (and DLTS) traffic. Unlike the android:usesCleartextTraffic attribute, this feature is not meant to be enabled in app builds distributed to users.
Firstly, this feature is supposed to flag secure traffic that is not TLS/SSL. More importantly, TLS/SSL traffic via HTTP proxy also may be flagged. This is an issue because as a developer, you have no control over whether a particular user of your app may have configured their Android device to use an HTTP proxy. Finally, the implementation of the feature is not future-proof and thus may reject future TLS/SSL protocol versions. Thus, this feature is intended to be used only during the development and QA phase.
Android N offers finer-grained control over cleartext traffic policy. As opposed to android:usesCleartextTraffic attribute, which applies to all destinations with which an app communicates, Android N’s Network Security Config lets an app specify cleartext policy for specific destinations. For example, to facilitate a more gradual transition towards a policy that does not allow cleartext traffic, an app can at first block accidental cleartext only for communication with its most important backends and permit cleartext to be used for other destinations.
It is a security best practice to only use secure network traffic for communication between your app and its servers. Android Marshmallow enables you to enforce this practice, so give it a try!
As always, we appreciate feedback and welcome suggestions for improving Android. Contact us at security@android.com.
Platform
Android Studio
Google Play
Android Jetpack
Docs
News
