Android is not secure, Google is not clear

The twenty-six letters of the alphabet have all been counted up to P, but the security of the Android ecosystem is still a worrying situation, and recently, this situation has even more concentratedly erupted.

At this year's Google I/O conference, Android platform security chief David Kleidermacher revealed while promoting Project Treble that Google will incorporate security patch updates into OEM agreements to allow more devices and more users to receive regular security patches.

This is a positive behavior, but upon closer inspection it is not worthy of praise, because the reason for proposing this plan is that someone had previously exposed his shortcomings.

Just in April this year, after testing 1,200 mobile phones of different brands and channels, the Security Research Lab stated that the installation of security patches was not satisfactory, and some manufacturers even missed at least 4 months of security patches.

The report comes just a month after Kleidermacher said in an interview with CNET that "Android is now as secure as its competitors."

Friendly Forces

Anyone who has used Google Pixel will have noticed that Google pushes a security update every month, and regardless of whether you want to update or not, Google doesn’t just push this security patch to its own phones.

For security issues, Google now releases a security patch bulletin on the first Monday of each month, which lists patches for known vulnerabilities. Major manufacturers generally receive this patch a month in advance, so that OEMs and suppliers, such as chip manufacturers, can fix the vulnerabilities before the announcement.

This idea is good, and if friendly forces implement it seriously, the effect will be good. For example, although the sales of Essential phones are not good, they can push security updates on the same day as Google Pixel.

However, as mentioned earlier, other manufacturers do not do this. Please see the picture to see the specific differences:

Security also pointed out that the chip suppliers are largely responsible for this result, because phones using MediaTek chips are even worse at getting security updates:

The relationship between updates and chip suppliers is not absolute. For example, PingWest has a Qualcomm Snapdragon 835 phone, and the current Android security update is still on December 1, 2017.

After this phenomenon was exposed, Google responded quickly, acknowledging the importance of the research and saying it would verify it. The final result was what was announced at Google I/O. And Google's Project Treble, which has been promoted for the past two years, can be used. Using this mechanism, manufacturers can make security patches more easily and at a lower cost.

Using policies to constrain manufacturers on the one hand and to reduce resistance on the other hand can be considered a very good strategy. But Kleidermacher probably never expected that while helping his allies, he would also mess up his own position.

Home

According to research by Symantec, a long-established security software company, some malicious apps that were once discovered have reappeared on Google Play, and the method used is very simple: changing their names.

There are 7 malicious applications discovered this time. They were reported to Google and removed as early as last year, but now they have re-entered Google Play as emoji keyboard, space cleaner, calculator, etc. by changing the package name.

Here is a brief introduction to the performance of these malicious applications, please pay attention:

• After installation, it will enter a silent period of several hours to avoid being noticed
• Using the Google Play icon to request administrator privileges
• Change your own icon to common applications such as Google Play and Google Maps
• Profit from providing content—such as redirecting websites—that is controlled by the cloud

Relatively speaking, the behavior of the malware this time is not important. What is more dangerous is the form of logging into Google Play and the problems in the Google Play security process.

First of all, Google Play's review mechanism is full of loopholes. In the process before the application is put on Google Play, security testing is a mere decoration, the automatic detection algorithm does not work at all, and the manual review is just a promotional title - according to Symantec, these applications cannot provide normal functions at all, so what is the manual review?

Secondly, the protection advertised by Google after the app was launched and installed by users did not work. Google Play Protect, which uses machine learning technology to identify rogue software and is said to scan billions of apps every day, was also bypassed.

What is most unacceptable is that these systems were bypassed twice, and the second time was just by changing the name. This inevitably makes people think that there is no "summarizing experience" in Google Play's security process, and whether the so-called machine learning is separated from learning and doing.

Compared with system vulnerabilities, malicious applications are more uncomfortable for users. After all, the possibility of most people's devices being deliberately exploited by vulnerabilities is close to zero, but if you install the wrong application, you will be directly attacked.

application

When it comes to malicious apps, many people naturally think of rogue apps, then think of the "family bucket", and then think of how Google has updated several management measures in recent years, and further think about why they still can't be suppressed.

In fact, Google should be blamed for this, because Google has never figured out the key point of the problem.

Take Android 8.0 as an example. Although Google has introduced a background control feature, there is a prerequisite for this feature to be fully functional. The package SDK of the application must reach API 26 (a development setting that is not user-oriented and is updated synchronously with the Android version. The current official version has a maximum API 27, and Android P is API 28). To put it bluntly, the application is developed for Android 8.0. If the application does not do this, the result is that the new feature can only play a small role at most, but it will not affect the normal use and abuse of the App.

Therefore, the control is in the hands of application developers. If they think that the new Android mechanism is great and should be followed, then they can use the new API. If the product department or push service provider thinks that the whole package looks good, then they can keep it as it is.

PingWest tested several apps in Google Play and found that the lowest one can be as low as API 18, and even some of Google's own apps are still at API 24. Outside of Google Play, Tencent's newly launched TIM is still using API 15 from the Android 4.0.3 era and having a lot of fun.

It can be seen that under the premise of this almost gentleman's agreement, it is nothing but a pipe dream in the short term to expect manufacturers to keep up and exercise self-restraint.

As for when this situation can be further improved, it depends on when Google realizes the importance of power.