Google has found a vulnerability that resides in the Android operating system’s kernel code and can be used to help an attacker gain root access to the device. Ironically, the vulnerability was patched in December 2017 in Android kernel versions 3.18, 4.14, 4.4, and 4.9, but newer versions were found to be vulnerable, ZDNet reported.
Information Security Buzz (aka ISBuzz News) is an independent resource that provides the experts comments, analysis and opinion on the latest Information Security news and topics
The real irony of this situation is that Google’s own automated bug hunting tools found the kernel bug and got it fixed in 2017 and yet the Pixel 2 is vulnerable in 2019. This shines a light on a dark spot in Google and Linux’s overall security postures. Google found the bug and reported it to the kernel developers who fixed it in their actively supported kernels. Unfortunately, there was no apparent process in place to communicate the need to port this security fix to the kernel source used for various existing devices.
New devices like Pixel 3 were not affected simply because the kernel was presumably forked after this patch, but it begs the question of what other kernel vulnerabilities will linger on those devices unless Google manages to close the loop on their security research process. Without a means to identify and backport kernel fixes with a regular cadence, Google’s valiant efforts to “make 0-day harder” may ultimately expose Pixel to more rather than less risk of attack.
In terms of preventing the flaw affecting a device, the old mantra of use the \”latest safe version\” still rings true here. It is easy to pick out examples of organisations accidently leaving legacy vulnerabilities in code after patching them in previous version, these reintroductions are part of the software development lifecycle and may not go away in the next decade. Regardless keeping your devices up to date using the latest safe versions is the most robust strategy unless your organisation has a mature patch triage team who can rubber stamp updates before they are deployed.
You should also be careful what permissions you give applications. In early 2018, the Google Play store was inundated with flashlight apps who siphoned off data from other applications stored on the device. Be vigilant with your applications and their permissions, these should be routinely reviewed and updated based on your usage. Be pragmatic about what permissions you are sharing. A flashlight application should not need access to your contacts or the ability to send SMS. Force controls such as strong passcodes or biometrics if supported. Weak passcodes such as 4 characters or repeating characters should not be allowed by default.