X
Tech

​Google Project Zero: How we cracked Samsung's DoD- and NSA-certified Knox

A Google Project Zero hacker offers Samsung a few self-defense lessons.
Written by Liam Tung, Contributing Writer
samsung-galaxy-s7-edge-out-about-26.jpg

Google Project Zero's Gal Beniamini details four key errors he used to bypass Knox's kernel protections on a Galaxy S7 edge.

Image: ZDNet

Google's Project Zero hackers have detailed several high-severity flaws that undermined a core defense in Samsung's Knox platform that protects Galaxy handsets in the enterprise.

Since launching Knox in 2013, the platform has been certified for internal use by UK and US government departments, including the US DoD and NSA. Given these certifications, defense-in-depth mechanisms should be rock solid.

But according to Project Zero's Gal Beniamini, who last year tore apart Android's full disk encryption, a Knox hypervisor designed to protect the Linux kernel during runtime can be subverted multiple ways.

Beniamini details four key errors he used to bypass Knox's kernel protections on a Galaxy S7 edge with Samsung's Exynos chipset. They're rather serious given that compromising the kernel would allow an attacker to access system data, hide malware, change system behavior, or take over the system.

While Android's Trusted Boot protects the integrity of the kernel during boot, it doesn't protect the kernel after it's booted and running. This shortcoming was why Samsung introduced its Knox hypervisor, known as Real-time Kernel Protection or RKP, which uses the ARM TrustZone to create a "secure world" walled from the "normal world".

Samsung fixed the six RKP issues reported by Beniamini in its January Android patch and lists them as memory corruption, information disclosure, privilege escalation, and authentication bypass bugs.

As Beniamini explains, since Knox v2.6, Samsung devices implemented an exploit-mitigation feature called Kernel Address Space Layout Randomization (KASLR), which should prevent an attacker predicting the address the kernel is loaded to. However, a simple coding error by Samsung made it possible to calculate the location.

"This security feature introduces a random 'offset', generated each time the device boots, by which the base address of the kernel is shifted. Normally, the kernel is loaded into a fixed physical address, which corresponds to a fixed virtual address in the VAS of the kernel. By introducing KASLR, all the kernel's memory, including its code, is shifted by this randomized offset, also known as a 'slide'," explains Beniamini.

However, as he notes, since all of the kernel is shifted by a single slide value, "leaking any pointer in the kernel which resides at a known offset from the kernel's base address would allow us to easily calculate the slide's value".

Beniamini says most Android devices correctly implement a function known as ktpr_restrictto hide a pointer's value using the anonymizing format specifier %pK, specifically with an upper case K. As Beniamini has previously highlighted, all kernel pointers printed using %pK are hidden. However, Samsung "rather amusingly" used a lowercase k.

"This allows us to simply read the contents of pm_qos, and subtract the pointer's value from its known offset from the kernel's base address, thus giving us the value of the KASLR slide," he explains.

Beniamini details three other RKP mitigations he got around, and several recommended steps Samsung could take to shield it from future attacks.

Read more about Google Project Zero

Editorial standards