Table of contents
Currently, Android is the most popular operating system in the World. This fact makes it attractive for all kinds of villains. Luckily for all, Google understands it too and made security a priority during the development of each new version of Android.
The thing is that most users don’t care about security changes, so we rarely hear about them during a presentation of a new version.
So if you want to please your curiosity on security changes in Android Oreo and get a bit deeper into it, this article is for you.
Let’s get started!
This initiative started as a way to make update process faster and easier for vendors. As a result, it turned into the biggest rework of internal components in Android since version 4.0.
Before Treble, the release of a system update was a real pain for everyone. Device vendors, hardware components manufacturers, as well as Google itself, suffered a lot. The root of the problem is the tight coupling of code in every component of the system along with the hardware-specific code. It took a lot of effort and time to do the changes and test them well. One by one, every participant had to iterate through that process again and again. And all together they had to pray that changes didn’t break everything completely.
As a result, most of the new devices left behind with no updates and security patches at all quite fast.
To deal with such hell Google decided to separate Android OS framework and vendor parts. In Oreo, all the low-level device-specific things work through a new vendor interface... At least on Google Pixel devices according to docs.
The image below is quite self-explanatory to get the idea of Treble.
Device-specific vendor implementation won’t require any changes with every new update of Android. And it works vice versa too — vendors can update their parts without breaking anything in Android OS.
It leads us to an idea that in the future users might be able to update drivers of their devices without updating the operating system. Just like on PCs. And the most obvious way to get these updates is to download them from Google Play Store.
I am convinced that Google should create a dedicated section for such drivers in the Play Store. And only verified parties (hardware vendors like Qualcomm, MediaTek, etc.) should release updates there. Without such section, we will definitely end up with lots of harmful clones of the drivers. Like we already see with clones of popular messenger apps like Facebook, WhatsApp, etc.
What does it mean for security?
With independent updates from hardware vendors, users will get a faster response on critical security issues. Like infamous recent Bluetooth problem called BlueBorne or fresh Wi-Fi’s WPA2 vulnerability KRACK.
Project Treble isn’t limited to separate Android OS and hardware-specific code. In Android Nougat, Google split MediaServer into components. The next stage was to create a bunch of hardware abstraction layers or HALs. In Oreo, things like audio, DRM servers and camera got HALs first. The main goal here was to separate processes and limit access to the kernel.
Looks like in future versions we will see further modularization of Android components.
Android Verified Boot 2.0
In Android 4.4 Google presented a mechanism called Verified Boot. This thing checks the integrity of OS components on device start up and forbids the load if loader, kernel or OS were modified.
With every new Android version, this mechanism received updates. But there still was a problem widely used by some bad guys to hack the device. The problem is a possibility to make a downgrade.
What? How on Earth downgrade can be a problem? — the first question which comes to a mind.
Well, a downgrade is used to get an access to device’s data by bringing back well-known vulnerabilities. It is a common practice among thieves, who want to get user’s data. Even data encryption isn’t a savior in such cases. For example, a few years ago Samsung had a vulnerability which allowed to bypass the lock screen and get an access to a smartphone. And with being able to revert firmware it isn’t a big deal to get into someone’s personal data.
As an example of such kind of attack, you can read this article written by some researchers from Florida State University and Baidu X-Lab.
In Android Oreo, Google finally resolved this issue with a Rollback Protection which is a part of Verified Boot 2.0. Partition with meta-data for Verified Boot now contains a so-called Rollback Index. This number increases for each image change. Moreover, the last seen rollback index is also stored in a tamper-evident storage.
Note: bootloader unlock will turn off Rollback Protection, so your device will become vulnerable again to this type of attack.
Unknown sources installations
Users always had an ability to install apps from sources other than Play Store. All they had to do is to go to device’s security settings and check on Allow unknown sources.
With Android 8.0, Google decided to bring a fine-grain control for this feature. As a result, users should provide a permission to an app which would like to install another app.
The image below shows how it can be done in Settings.
This step should protect users from harmful downloaders. In theory, it should make a silent install impossible.
Believe it or not, but Google has finally implemented a MAC-address randomization. This feature appeared in iOS in version 8 (What a coincidence!) released in 2014. Randomization is a good way to improve privacy and avoid unintended identification by 3-rd parties.
In Oreo, it is used during background network scanning I mentioned in my previous article. With every scan of surrounding Wi-Fi networks, the system will generate a random MAC address value. The very first packet sequence number for each scan is also randomized.
Sounds great until we find out that this feature requires manufacturers to update the firmware of Wi-Fi chipsets first. Nexus 5x and Pixel devices (Pixel 2 and 2 XL don’t need it) were the first to get their updates. Let’s hope other vendors will do the same along with updates to fix KRACK vulnerability.
Another sad fact is that this is not enough to provide privacy. As it seems from this study MAC randomization mechanism isn’t great and your device can still be identified.
Unique identifiers handling
MAC-address isn’t the only thing used to identify your device. Google decided to take care about other identifiers too. Changes include:
- Android ID (SSAID) generated during device’s first boot, will have a different value for each app and each user of the device. This ID will stay the same until the app is reinstalled. All apps installed before updating a device to Android Oreo will have their old Android ID.
- For advertising purposes, developers got the new Advertising ID resettable identifier. This identifier provides end-user with more control on his data.
- As earlier developers had to ask permission to get IMEI of the device, now they have to do so to get a serial number. Instead of android.os.Build.SERIAL developers are encouraged to use Build.getSerial() method, which returns the serial number if the app has PHONE permission. Moreover, in the future release of Android, all apps targeting Oreo will see Build.SERIAL as UNKNOWN.
- Network hostname of the device is empty in Android O. Previously, DHCP client could return hostname. It is not that good for privacy and to meet requirements of IETF RFC 7844 standard it was changed.
- Bluetooth MAC address can be obtained only if the app has LOCAL_MAC_ADDRESS permission.
More info about such changes can be found here.
Linux kernel, which is a base of Android, gives access to a lot of cool features to advanced users. Unfortunately, they are also used by bad guys to compromise Android Security system.
Developers from Android Security team decided to do a cleanup and restrict the number of available features. As a result, Android Oreo got a seccomp filter (short from Secure Computing in Linux).
The filter has to block certain system calls (syscalls), which were previously used or could be potentially used for security attacks. This filter blocks 17 of 271 syscalls in ARM64 and 70 of 346 in ARM.
Android Security team claims they tried to avoid compatibility problems with existing apps. More about that can be found in official Developers Blog.
Permissions under control
In Android 6.0 a new permissions request system appeared. Developers had to change their apps to ask for permissions explicitly. It improved an overall system security as users could see when the app tries to use something like microphone or location.
Yet, there was an official way to bypass it — developers could leave targetSDK lower than 23. In this case, no requests would appear at all. Some popular apps use this approach. For example, Snapchat uses it to avoid dealing with runtime permissions.
In Oreo, Google started to enforce runtime permissions. Unfortunately, not all permissions are enforced to be checked at a runtime now. Snapchat can still use almost everything on our Pixel device with Android Oreo on board. In future updates all dangerous permissions will have to be requested explicitly.
Alert windows fixed
Android has a permission called SYSTEM_ALERT_WINDOW. It allows the app to display something on top of another app or screen. The problem is that it was abused by some hackers to create a ransomware or steal credentials. Google has finally looked at it and changed how everything works to stop the flow of malicious apps and annoyed users.
Starting with O the system can completely control the overlay windows, so user can always resize, close or forbid them at all. Additionally, app’s alert windows will always appear under status bar and other system windows, like IMEs.
Google Play Protect
It is not an exclusive feature of the new Android anymore. It was there since Android 4.2 and had a name Verify Apps. It is an antivirus software used to check all installed apps. When user’s device has an internet connection it checks every app, including apps, installed not from Google Play Store. You don’t see the battery drain, because apps check happens while the device is charging.
Most users didn’t know about such kind of antivirus software. And still don’t know, to be honest. So, they install 3-rd party solutions to protect their data and devices. Usually, it only causes a slow down of the device.
To show users that they are under protection Google designed an interface called Google Play Protect. Oreo users can find it in Security section of device’s Settings. Others — in Security section of Google Settings.
Oreo users can also see the result of app check of any application on its page in Google Play Store.
Developers got access to a SafetyNet Verify Apps API. It allows to check if the device is protected with Verify Apps, ask a user to activate it or limit app’s functionality based on the result of this check.
In theory, we should be happy with such a great thing, but in reality, Google Play Protect isn’t a silver bullet to protect your device. According to a recent test by AV-Test, it showed the worst results among all Android protection solutions. In fact, this is the only one there with 0 (yes, it is zero) points for protection.
Let’s keep our fingers crossed that it will be fixed really soon.
Protect your input
Another feature not exclusive for Android Oreo anymore. Recently Google made it available to older Android versions with their Gboard updates. But its debut happened in Preview 2 of Android Oreo. The keyboard got an Incognito mode. Just like your web-browser.
Google promises that in Incognito mode everything you type won’t be remembered or used for suggestions. Now you don’t have to worry that keyboard will remember sensitive data or learn something bad to suggest it later while somebody else is using your phone :)
For now it is limited only to Chrome and other Chrome based browsers. There is no doubt users will get an ability to turn it on in other apps too one day.
DNS over TLS
Every time user types a name of a website a request to DNS or Domain Name Server is performed to get an IP address of this website. Only after getting an IP address browser can establish a connection with this website. And for years this part didn’t have an encryption.
While HTTPS helps to protect user’s data, DNS requests are still done in plain text. Without any encryption. So even if your ISP (Internet Service Provider) can’t see the exact data flow between the device and some server, it can see where the data goes.
Seems that this issue is going to be fixed. And it might happen in Android 8.1 which should arrive quite soon. These merged commits to AOSP (Android Open Source Project) confirm that.
Of course, it won’t completely hide your data, because instead of ISP, it will be visible to a DNS service provider. And for now, it is better than nothing.
In this case, it is not only about privacy, but a move to overcome the end of net neutrality.
WebView is secured
WebView is a basic component used by a variety of different apps. And if browsers get their updates really often, WebView doesn’t.
With Oreo, WebView got a serious update too. Now it has its own process. And its Web content is handled in a sandbox to isolate possible harmful things.
What could be better?
There are much more changes, especially low-level ones, made to improve security and privacy. Frankly, it would take a whole day to list them all. I’ve tried to list the most important ones, especially those interesting for developers.
Many security researchers and experts say that Android Oreo is a serious step forward in terms of security of the platform. After digging through different docs, articles, and reports it is not that hard to see why.
Despite some minor flaws like with Google Play Protect, it is still a great update of the most popular OS.
We, at UPTech, have already updated almost all our projects to target new Oreo SDK to integrate cool new features and additional security updates.
What do you think about the security in Android Oreo? Let us know in the comments below.