Google recently released their newest operation system (OS) for Google made devices. The OS, named Fuchsia, is making waves among the technology and security industry. At face value, this operating system functions much like its predecessors, but there are many new and interesting features under the surface that are worth exploring.
One such feature is the kernel, which Google developed to target the AARch64 and x86_64 architectures. This kernel is a custom-built micro-kernel, which means it is comprised of only the necessary kernel-mode services, drivers, and libraries needed for system functions. It has more stringent security principles by design, setting it apart from other operating systems like Linux, Android, and Chrome OS.
Google’s production of Fuchsia is a significant step for the creation of more secure applications. Not only does it have heightened security through its use of a microkernel, but throughout its core values, which means it was integrated into the software from the kernel up. As a result, there is a range of security advantages offered by Fuchsia that include a smaller attack surface for the kernel and increased difficulty in completing direct-to-kernel exploits.
Fuchsia is currently commercially available – albeit in a limited capacity – so anyone can grab the source, compile, and build on this OS. Because of this, it is necessary to understand the fundamentals of Fuchsia to determine if it is a viable operating system for creating secure applications. As such, this blog post highlights the fundamentals of Fuchsia and explores how this is a step in the right direction for application security.
All operating systems are built on kernels, which are lines of code that act as a bridge between applications and the data processed within the hardware. As demonstrated in the diagram below, kernels are the communicator to the application, and they have access to all core functions within the software. Meaning, when kernels are exploited, attackers can gain access to all facets of the operating system. These types of attacks are called direct-to-kernel exploits, and can cause irreparable damage to the software. Direct-to-kernel exploits have repercussions that span throughout the entire OS – including applications developed on that system.
Google’s Fuchsia is built on a microkernel, which is a type of kernel that includes only the bare minimum number of lines of code needed to function at the kernel mode. Micro-kernels differ from their counterparts, monolithic kernels, in how they move most components out of the kernel and place them into user mode. For example, in micro-kernels, only vital kernel functions like Inter-Process Communication (IPC) and scheduling are found at the kernel-mode, whereas all other functions are moved to the user space. In comparison, monolithic kernels have nearly every function – vital or not – at the kernel mode and few in user mode.
Google’s Fuchsia operating system is a microkernel called Zircon that is written in C++. According to Google, they created this operating system “to meet the needs of today’s growing ecosystem of connected devices,” and they cite security as one of the primary reasons for its development.
“Security and privacy are woven deeply into the architecture of Fuchsia. The basic building blocks of Fuchsia, the kernel primitives, are exposed to applications as object-capabilities. This means that applications running on Fuchsia have no ambient authority: applications can interact only with the objects to which they have been granted access explicitly.”
A visual representation of Fuchsia’s architecture is seen in the diagram below.
Notably, the Zircon microkernel is organized into components, all of which reside in the user space. This intentional design choice heightens security because if one component has a vulnerability, it stays within that component and only affects its processes.
Because Fuchsia is built on the Zircon microkernel, the typical exploits that can impact other operating systems built on monolithic kernels – like Linux or Android – no longer hold the same weight. By nature of the kernel, Zircon has little to no attack surface or attack vectors. Instead, it moves the surface and vectors into the user mode, which silos them and creates a barrier between the components and kernel. Doing this makes it increasingly more challenging to complete a direct-to-kernel exploit because standard methods for an attack, such as Remote Code Execution (RCE), do not grant access to the kernel. Instead, they only give the attacker control over the component targeted, which runs independently of other components and kernel.
According to VerSprite Director of Security Research, Robert Hawes, successfully completing a direct-to-kernel exploit with Zircon is not impossible but requires advanced skills, creativity, and adequate time. Fuchsia “now requires an additional vulnerability within an exploit chain in order to complete that full chain attack,” Hawes says. This makes it exponentially more challenging for the average attacker to complete a Direct-To-Kernel attack because the attack surface and vectors have all but been eliminated.
When attacking monolithic kernels, common targets are the vulnerabilities found in Transmission Control Protocol/Internet Protocol (TCP/IP) or Bluetooth. However, with Fuchsia, these now exist within the user mode and will not give kernel access to an attacker. Hawes says, “this Direct-To-Kernel attack is now a Direct-To-User attack, meaning that an attacker would still need a Local Privilege Escalation (LPE) vulnerability to achieve kernel access.” This means vulnerabilities typically found within other operating systems are likely to be found in Fuchsia, but they have little to no impact on security due to Fuchsia’s security properties.
Currently, Fuchsia is only found in the oldest version of Google Nest Hub. Our experts theorize this is likely because this older device gives a less intense trial for how the system will operate and how the security will hold up.
Google has not announced plans to integrate Fuchsia into any of its other products. However, Google SVP, Hiroshi Lockheimer, is quoted saying, “Fuchsia is about just pushing the state of the art in terms of operating systems and things that we learn from Fuchsia we can incorporate into other products.”
There is no way to tell what Google will do next with Fuchsia, but the security standards it sets are promising.
While Fuchsia demonstrates elevated operating system security standards, many applications were and continue to be developed on monolithic kernels. As shown, these kernels offer much less protection from common exploits, like RCE, and application security services are needed to protect organization’s and user’s data.
To best protect themselves, organizations should enlist specialized help with application security. That’s where we can help. VerSprite’s OffSec team focuses on applying security through measurable technology. Our team emulates cybercrime and simulates test scenarios that reflect current attack patterns and threat motives that can increase protection, even when applications are built on faulty ground. Contact our security advisors to learn more about risk-based application security →
Maintain awareness regarding unknown threats to your products, technologies, and enterprise networks. Organizations that are willing to take the next step in proactively securing their flagship product or environment can leverage our zero-day vulnerability research offering. Our subscription-based capability provides your organization with immediate access to zero-day vulnerabilities affecting products and software. Learn More →
View our security advisories detailing vulnerabilities found in major products for MacOs, Windows, Android, and iOS.