Fuchsia OS Attacked: Here's What Was Found

Google’s Fuchsia OS — an emerging operating system that the company has quietly been developing — may not be running on any production systems yet and still remain something of a strategic mystery. (What will it be used on? When will it be rolled out, if at all?)

That hasn’t stopped security researchers from Quarks Lab — a French security R&D and software development company — from attacking it. (The OS code base is open source). After all, as they note, it could end up on hundreds of millions of Android and Chrome devices.

Fuchsia OS: Some Context

A couple of things that Computer Business Review has widely covered are important context for the security probe. (These won’t be much surprise to Fuchsia’s followers of the past two years.)

i.e. Fuschsia OS is based on a tiny custom kernel from Google called Zircon which has some elements written in C++, some in Rust. Device drivers run in what’s called “user mode” or “user land”, meaning they’re not given fully elevated privileges. This means they can be isolated better.

In user land, everything that a driver does has to go via the kernel first before hitting the actually computer’s resources. As Quark Labs found, this is a tidy way of reducing attack surface. But with some sustained attention, its researchers managed to get what they wanted: “We are able to gain kernel code execution from a regular userland process.”

Attacking Fuchsia OS

“Contrary to every other major OS, it appears rather difficult to target the Zircon kernel directly. A successful RCE (Remote Code Execution) on the world-facing parts of the system (USB, Bluetooth, network stack, etc) will only give you control over the targeted components, but they run in independent userland processes, not in the kernel. From a component, you then need to escalate privileges to the kernel using the limited number of syscalls you can access with the handles you have” the firm noted.

Its initial attempts to find vulnerabilities ran into dead ends or resulted in minor bugs, among them an out-of-bands access issue relating to USBs: “Fuchsia will fetch descriptor tables from the device as part of the USB enumeration process. This is done by a component in the USB devhost. The component… has a bug when handling configuration descriptor tables”. This would allow a determined attacker to perform out-of-bounds accesses, although still only in userland. Google has now fixed this.

It also found two different minor bugs in the Bluetooth stack: one relating to how it handles reject packets: “Not an interesting bug from an exploitation point of view, (un)fortunately.” The other in parsing ServiceSearchResponse packets. Again, this could, at best, allow a limited Denial Of Service attack on the Bluetooth component. As the investigators put it: “Not interesting! :'(”

But when they got to an embedded hypervisor for AArch64 and x86_64 things got a little more interesting. (It was unclear to the Quark Lab team why the hypervisor was there: They speculated to help the transition from Googles’ other OSs to Fuchsia, e.g. by “having a guest Android or Chrome OS system run in a VM and execute Android or Chrome OS applications.”)

A bug in the handling of a vmcall instruction for example (the hypervisor did not verify where the call came from) could, ultimately, be used in privilege escalations from the guest userland to the guest kernel.

“There, an attacker has more hypervisor interfaces available, and from there a VM escape vulnerability can be researched and leveraged…”

The TLS on Zircon

In another attack, they found that the kernel uses the structure located at FakeTlsAddr thinking it is a trusted x86_percpu structure from the kernel whereas it is actually a structure possibly controlled by userland. “By placing a specific value in the gpf_return_target field of this fake structure, userland can begin to gain code execution in kernel mode.”

In short, Fuchsia’s unique security properties “do not – and in fact, cannot – hold in the lowest layers of the kernel related to virtualisation, exception handling and scheduling, and that any bug here remains exploitable just like on any other OS.” Despite this, they concluded, it has the potential to “significantly increase the difficulty for attackers to compromise devices.”