Code changes intended to prevent attacks can wind up creating even more security issus, Google Project Zero warned.
Several smartphone makers add device-specific code to Android’s Linux kernel to protect the device from attacks, but they frequently “introduce subtle issues” into the codebase, said Jann Horn, a researcher with Google Project Zero. Modifications are being added downstream without any review from upstream kernel maintainers. Instead of making changes to kernel code, the handset makers would be better off using the security features already present in the Linux kernel, Horn said.
Horn was referring to how Samsung added custom drivers to its Galaxy A50, and how the new code created a memory corruption flaw. The moderate-severity issue, which impacted Samsung’s Process Authenticator (PROCA) security subsystem, consisted of use-after-free and double-free vulnerabilities on devices running Android 9 (Pie) and Android 10. If successfully exploited, arbitrary execution would have been possible.
“Unfortunately, it is more difficult to generically lock down the attack surface that is created when vendors modify core kernel functionality,” Horn said.
Google reported the flaw to Samsung in November. The fix was part of Samsung’s February security updates for Galaxy devices.
While Horn called out Samsung specifically for adding custom drivers for direct access to the kernel, this is a common practice among smartphone manufacturers. Samsung is not the only culprit.
“Ideally, all vendors should move towards using, and frequently applying updates from, supported upstream kernels,” he said.
Android has been locking down which processes have access to vendor-specific device drivers in order to reduce the security impact of the modifications. When smartphone makers introduce their own changes, it negates the work already done to make Android more secure, Horn said.
For example, Samsung added extra protection to credential structures by making some areas read-only, and adding checks to others, but none of those modifications “actually prevent an attacker who has sufficient control over the kernel to modify credential structures from reading or modifying user data directly,” Horn said. For example, an attacker would be able to modify file-system-internal data structures to get access to areas that wouldn’t be accessible normally, or directly read secrets from kernel memory.
“Samsung's protection mechanisms won't provide meaningful protection against malicious attackers trying to hack your phone, they only block straightforward rooting tools that haven't been customized for Samsung phones,” Horn said.
Engineering resources could’ve been better utilized by trying to make sure the attacker never made it to this point.
"I believe that device-specific kernel modifications would be better off either being upstreamed or moved into userspace drivers, where they can be implemented in safer programming languages and/or sandboxed, and at the same time won't complicate updates to newer kernel releases," explained Horn.