You Can Rand but You Can’t Hide: A Holistic Security Analysis of Google Fuchsia’s (and gVisor’s) Network Stack

You Can Rand but You Can’t Hide: A Holistic Security Analysis of Google Fuchsia’s (and gVisor’s) Network Stack

Speakers: Amit Klein, Hebrew University of Jerusalem

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=RLdbNoVkYIE

Overview

This talk, presented by Amit Klein from the Hebrew University of Jerusalem, delves into a comprehensive security analysis of the network stacks within Google Fuchsia and Google gVisor. Fuchsia, a general-purpose operating system designed for a diverse hardware and software ecosystem, is already deployed on millions of Google Nest Hub devices and is widely conjectured as a potential successor to Android. Crucially, its TCP/IP stack, known as netstack, is a direct copy of gVisor's network stack, which serves as an application kernel for containers across multiple Google Cloud offerings including App Engine, Cloud Functions, and Google Kubernetes Engine (GKE). This shared codebase means that vulnerabilities discovered in one often impact the other, highlighting the broad security implications of this research.

The presentation outlines a "holistic security analysis" approach, meticulously examining the entire TCP/IP stack of both Fuchsia and gVisor. The research specifically targets high-entropy protocol header fields, which are typically assumed to be random and unpredictable, such as IPv4/IPv6 IDs, TCP source ports, TCP timestamps, and TCP Initial Sequence Numbers (ISN). By identifying weaknesses in the generation and management of these fields, the researchers were able to chain together seemingly minor vulnerabilities across different network layers and components to forge powerful and practical attacks.

The core contribution of this work lies in demonstrating that even "clean slate" designs, like those often touted for modern operating systems, do not inherently guarantee a secure codebase if fundamental security principles, particularly around randomness and state management, are overlooked. The findings revealed critical flaws that allowed for the prediction of future network header values and, more alarmingly, the creation of a persistent, cross-site device tracking mechanism using the network stack's internal state. Google has since addressed these vulnerabilities based on the researchers' recommendations, underscoring the impact and importance of this detailed security analysis.

Background

▶ Watch: Introduction to Fuchsia, gVisor, and research scope (0:00)

Google Fuchsia emerged as a highly anticipated operating system, envisioned to power devices ranging from mobile phones and tablets to Internet of Things (IoT) devices. Its deployment on Google Nest Hub devices signifies its growing presence in the consumer market, and its potential to eventually replace Android positions it as a critical component of Google's future ecosystem. Concurrently, Google gVisor functions as an application kernel, providing enhanced security and isolation for containers across various Google Cloud services. The strategic decision to share a common network stack—Fuchsia's netstack being a direct copy of gVisor's—created a unified attack surface, meaning that a vulnerability in one often replicated in the other, amplifying the potential impact of any discovered flaws.

The motivation behind this research stemmed from the observation that while new systems are often designed with modern architectural principles, security vulnerabilities can still arise from subtle implementation details, particularly concerning the generation of seemingly random values. The researchers adopted a holistic security analysis methodology, scrutinizing the entire TCP/IP stack rather than isolated components. This approach allowed them to identify how minor weaknesses, when combined, could lead to significant security breaches. The focus was specifically on high-entropy protocol header fields, which are crucial for the security and stability of network communications. These fields, such as the IPv4 ID, IPv6 ID, UDP source port, TCP source port, TCP timestamp, and TCP Initial Sequence Number (ISN), are expected to be sufficiently randomized to prevent an attacker from predicting their values. Such predictability can enable various attacks, including connection hijacking, device tracking, and bypassing network security mechanisms.

Prior work in network stack security has frequently explored the predictability of these fields, often leading to discoveries of weaknesses in older or less robust implementations. However, Fuchsia and gVisor, being relatively modern "clean slate" designs, presented a unique challenge and opportunity. The common assumption is that such new designs would incorporate lessons learned from decades of network security research, particularly regarding cryptographic randomness and robust state management. This research aimed to test that assumption, revealing that even with a clean architectural design, security is often found in the meticulous details of implementation, and overlooking established best practices can introduce significant vulnerabilities. The fact that the IPv6 flow label was found to be consistently zero, for instance, immediately signaled a potential lack of randomization or deliberate design choice that could be exploited if other fields were also weak.

Key Findings

▶ Watch: Focusing on TCP/IPv6 attack to find PRNG seed (3:55)

The holistic security analysis uncovered six distinct vulnerabilities within Google Fuchsia's and gVisor's shared network stack, which, when combined, facilitated powerful and practical attacks. The researchers demonstrated how relatively weak security flaws in individual network protocol headers and layers could be synergistically exploited to compromise the system's internal state and facilitate various forms of information leakage and tracking.

The primary objective of several combined attacks was to discover the network stack's Pseudo-Random Number Generator (PRNG) seed, a critical 31-bit value that governs the generation of many "random" network parameters.

• TCP/IPv4 Attack: This attack combined four distinct vulnerabilities and required the observation of four TCP SYN packets. By analyzing these packets, attackers could deduce the 31-bit PRNG seed.
• TCP/IPv6 Attack: A more efficient variant, this attack leveraged only three vulnerabilities and required just two TCP SYN packets to discover the same 31-bit PRNG seed. This was the attack vector chosen for a detailed explanation during the presentation due to its efficiency.
• UDP Attack (Rainbow Table): This sophisticated method employed a rainbow table attack and, remarkably, required zero network packets. The researchers demonstrated that by forcing the operating system and browser (e.g., using WebRTC) to allocate UDP source ports without sending actual network traffic, they could still determine the PRNG seed.

Once the PRNG seed was compromised, a cascade of further information leakage and predictive capabilities became possible:

• IPv4 Internal Address and ID Hash Key: By combining the PRNG seed with another vulnerability related to the IP ID and employing a hash code attack with approximately 250 packets, attackers could discover an additional 32-bit IPv4 ID hash key. This key, combined with the PRNG seed, allowed for further prediction of fields and leakage of internal network information.
• UDP Port Prediction: Exploiting a PRNG advancing weakness in conjunction with the zero-packet UDP trick, attackers could predict future UDP source ports, which has implications for bypassing firewall rules or targeting specific services.
• TCP Secret Prediction: The discovered PRNG seed directly enabled the prediction of various TCP secrets, including the keys used for TCP timestamp, TCP source port, and TCP ISN (Initial Sequence Number) generation. This ability to predict future values for these critical header fields opens avenues for connection hijacking and other sophisticated network attacks.
• Information Leakage: Beyond direct prediction, the attacks also allowed for the leakage of non-obvious internal system information, such as the TCP outbound connection counter and the machine time since boot, providing valuable insights into the device's operational state and activity.

These findings collectively demonstrated that the "randomness" in Fuchsia's and gVisor's network stacks was significantly weaker than assumed. The ability to derive a stable 31-bit ID, persistent across various network conditions and even browser privacy modes, represented a severe privacy concern, enabling robust device tracking. The researchers' discovery of these interconnected vulnerabilities underscored a fundamental flaw in the network stack's design philosophy regarding entropy and state management, proving that a holistic approach was essential to uncover such systemic weaknesses.

Technical Deep Dive

▶ Watch: Understanding TCP timestamp generation and its weakness (4:00)

The core of the presented attack focused on the TCP/IPv6 scenario, demonstrating how to find the 31-bit network stack PRNG seed using just two TCP SYN packets. This attack hinged on three key vulnerabilities: the small PRNG seed itself, a weak hash function used for TCP timestamps, and a global counter mechanism for TCP source ports.

The process begins with understanding how the TCP timestamp is generated. As shown by the researchers, the timestamp value is calculated using the following equation:

Timestamp = hash(Source_IP || Destination_IP, Secret_Key) + Time_in_Milliseconds

The hash function employed here is a variant of Jenkins one-at-a-time hash. While Jenkins hash functions are generally robust, in this specific implementation, it suffered from a crucial weakness: a small internal state of only 32 bits. This limited state makes the hash function susceptible to "peeling," a technique where if the output hash of X and a known state is known, and X is also known, the initial state can be easily recovered. The researchers also highlighted the chaining rule for this hash function: hash(X || Y, state) is equivalent to hash(Y, hash(X, state)). This property is crucial for the attack.

The Secret_Key mentioned in the timestamp equation is one of the TCP secret keys, generated deterministically from the 31-bit PRNG seed at kernel startup. This means the key remains constant from system boot until shutdown, making it a stable target for an attacker.

Applying the chaining rule to the timestamp equation simplifies it significantly. The term hash(Source_IP || Destination_IP, Secret_Key) can be rewritten as hash(Destination_IP, J), where J is hash(Source_IP, Secret_Key). Thus, the timestamp calculation becomes:

Timestamp = hash(Destination_IP, J) + Time_in_Milliseconds

The primary objective is to find this unknown 32-bit quantity J. The attacker initiates this by forcing the Fuchsia device, typically through malicious JavaScript on a compromised website or via WebRTC, to send two rapid TCP SYN packets. These packets are directed to two different attacker-controlled IP addresses. The rapid nature of the packets ensures that the Time_in_Milliseconds component in the timestamp calculation is nearly identical or differs by a very small, bounded amount (e.g., within 20 milliseconds, as capped by the researchers).

Let TS1 and TS2 be the observed timestamps for the two packets sent to Dest_IP1 and Dest_IP2 respectively.

TS1 = hash(Dest_IP1, J) + T1

TS2 = hash(Dest_IP2, J) + T2

By subtracting these equations and rearranging terms, the researchers arrived at a critical equation where the left-hand side consists of values entirely known to the attacker (observed timestamps and destination IPs):

TS1 - TS2 - (T1 - T2) = hash(Dest_IP1, J) - hash(Dest_IP2, J)

Since the time difference (T1 - T2) (denoted as delta T in the talk) is small and bounded (e.g., within 20 values), the left-hand side can be computed for each of these 20 possible delta T values. The right-hand side is a function of J and known destination IPs. This function F(J) = hash(Dest_IP1, J) - hash(Dest_IP2, J) can be precomputed offline. By inverting this function into Q, the attacker can feed the known left-hand side values into Q to obtain a small set of J candidates (up to 20 candidates, corresponding to the possible delta T values).

Once J candidates are obtained, the next step is to recover the Secret_Key and then the 31-bit PRNG seed. Recall that J = hash(Source_IP, Secret_Key). Since J is now known (or a small set of candidates), and the Source_IP is also known, the "peeling" technique can be applied to invert the hash function and find the Secret_Key candidates.

Finally, the Secret_Key is deterministically generated from the 31-bit PRNG seed at system startup. The researchers developed a multi-function W that inverts this generation process. Feeding the Secret_Key candidates into W yields a small set of 31-bit PRNG seed candidates (again, up to 20 candidates).

To verify the correct seed, the researchers leveraged another vulnerability: the TCP source port global counter. From the discovered PRNG seed, they could deterministically generate all other TCP secrets, including the TCP source port secret key prime. This key is used to generate TCP source ports. By comparing the source ports observed in the two initial TCP SYN packets with the source ports predicted by each seed candidate using the derived secret key prime, the attacker can uniquely identify the correct 31-bit PRNG seed. Only the correct seed will produce matching source port predictions.

The entire process is remarkably efficient, requiring only a few opcodes at runtime, 20 table lookups in Q, and 20 table lookups in W. The authors mention "modest RAM, only 56 GB," which likely refers to the offline precomputation for the inversion functions and candidate generation, rather than the runtime attack itself. This technical deep dive illustrates the intricate combination of cryptographic weaknesses and state management flaws that allowed for the complete compromise of the network stack's core randomness.

Demo / Proof of Concept

▶ Watch: Attack method: finding PRNG seed using two SYN packets (5:00)

The most compelling demonstration of the discovered vulnerabilities was the web-based device tracking, or cross-site tracking, mechanism. This proof of concept leveraged the stability and uniqueness of the 31-bit PRNG seed, once extracted, to persistently identify a device across various privacy-preserving scenarios.

The scenario unfolds as follows:

1. First Interaction: A mobile Fuchsia device connects to a website (e.g., website1.com). The malicious JavaScript embedded in website1.com executes the TCP/IPv6 attack, extracts the 31-bit PRNG seed, and uses it to generate a unique device ID. This ID is then stored by website1.com for future identification.
2. Subsequent Interaction (Different Network/Browser): On a later day, the same Fuchsia device connects to a completely different website (e.g., website2.com). This could be from a different network, using a different browser (e.g., Firefox instead of Chrome), or even after clearing browser cookies and local storage. website2.com, also containing the malicious JavaScript, re-executes the attack, extracts the same 31-bit PRNG seed, and thus regenerates the identical device ID.
3. Enhanced Privacy Mode Interaction: The device might then visit a third website (e.g., website3.com) while in an incognito or private browsing mode. Despite the heightened privacy settings, the attack can still extract the same 31-bit PRNG seed, leading to the generation of the identical device ID.

The "magic" behind this persistent tracking is the stability of the 31-bit PRNG seed. This seed is:

• Stable across sites: The same seed is extracted regardless of the domain or server the device connects to.
• Stable across browsers: Different browser applications on the device yield the same seed.
• Stable across networks: Changing from Wi-Fi to cellular data, or connecting to different Wi-Fi networks, does not alter the seed.
• Stable across privacy modes: Incognito or private browsing modes, which typically isolate browsing data, do not prevent the extraction of this network stack-level ID.
• Regenerated only on boot: The seed only changes when the Fuchsia device is rebooted.

This 31-bit seed provides a unique identifier, sufficient for tracking purposes given its entropy (unique up to the birthday paradox). The researchers conducted experiments on four different Google Fuchsia devices across seven distinct networks, consistently obtaining "excellent results," confirming the reliability and effectiveness of this tracking method.

Furthermore, the researchers also discussed how a dual-stack (IPv4 and IPv6 enabled) device could yield even more identifying information. By sending an additional TCP/IPv4 SYN packet, an attacker could obtain the device's IPv4 internal address. Combined with the IP ID vulnerability and a hash code attack, this could reveal another 32 bits, the IPv4 ID hash key, further enriching the device's unique identifier.

This proof of concept effectively demonstrated that the "clean slate" design of Fuchsia and gVisor did not protect against fundamental flaws in their randomness generation and state management. The ability to create a persistent, cross-site device ID directly from the network stack represents a significant privacy concern, as it bypasses traditional browser-based tracking protections (cookies, local storage) and is difficult for users to detect or mitigate without a device reboot.

Defensive Implications

▶ Watch: Practical impact: web-based device tracking using seed (7:00)

The detailed analysis by Amit Klein and his co-authors provided clear insights into the root causes of the identified vulnerabilities, leading to actionable recommendations for improving the security posture of network stacks in Fuchsia and gVisor. The researchers identified four primary root causes:

1. Weak Hash Function: The use of a simplified Jenkins one-at-a-time hash with a small 32-bit internal state for TCP timestamp generation was a critical vulnerability. This allowed for the "peeling" attack to reverse-engineer parts of the network stack's internal state.

• Defensive Recommendation: Replace the weak hash function with a cryptographic hash function. Cryptographic hashes are designed to be collision-resistant, one-way, and have a sufficiently large output to prevent inversion and prediction, thereby making attacks like peeling impractical.

1. Weak PRNG (Pseudo-Random Number Generator): The 31-bit PRNG seed, while providing some entropy, was insufficient and its deterministic generation of various secrets made it a single point of failure. Once discovered, it allowed for the prediction of numerous future network parameters.

• Defensive Recommendation: Migrate to a cryptographic PRNG (CSPRNG). CSPRNGs are designed to be unpredictable, even if an attacker knows previous outputs. They typically use larger seeds and more robust algorithms, making it computationally infeasible to guess future outputs or reverse-engineer the seed.

1. Global Counter for TCP Source Ports: The use of a global counter for generating TCP source ports introduced predictability. While not directly detailed as the primary attack vector in the presentation (the TCP/IPv6 attack primarily used it for verification), its global nature contributes to a weaker overall entropy pool.

• Defensive Recommendation: Implement fully randomized TCP source ports. This means that each new connection should use a source port chosen pseudo-randomly from the available range, making it difficult for an attacker to predict the next source port and reducing the utility of source ports for tracking or side-channel attacks.

1. Weak Generation ID Scheme (IP ID): Similar to the global counter for TCP source ports, the generation scheme for IP IDs also exhibited weaknesses that allowed for prediction or leakage of information.

• Defensive Recommendation: Ensure fully randomized IP IDs. The IP Identification field should be a unique, unpredictable value for each packet sent, preventing attackers from using it for host fingerprinting, tracking, or as part of more complex attacks that rely on sequential or predictable IDs.

Crucially, the researchers confirmed that Google went on and fixed Google Fuchsia and gVisor according to their recommendations. This swift action underscores the severity of the findings and Google's commitment to addressing fundamental security flaws in their critical infrastructure. The fixes likely involved upgrading the underlying cryptographic primitives, increasing seed sizes, and adopting industry best practices for generating random values across the network stack.

This research serves as a vital reminder that even for "clean slate" designs, learning from past mistakes and adhering to established security engineering principles—especially concerning randomness and state management—is paramount. A holistic security analysis, which considers the interplay of various components and layers, is essential to uncover systemic weaknesses that might be missed by isolated audits. For defenders, the key takeaway is the need for continuous vigilance and the adoption of strong cryptographic primitives for all security-sensitive random number generation, even in seemingly minor protocol header fields.

Key Takeaways

• Holistic Analysis Reveals Systemic Flaws: The research demonstrates that a comprehensive, "holistic" security analysis of an entire network stack can uncover interconnected vulnerabilities that, when combined, lead to powerful attacks, even if individual flaws appear minor.
• "Clean Slate" Does Not Guarantee Security: Google Fuchsia and gVisor, despite being modern "clean slate" designs, were found to have fundamental security weaknesses in their network stack due to overlooking established best practices for randomness and state management.
• PRNG Seed as a Stable Device ID: The ability to extract the 31-bit PRNG seed from the network stack allows for a persistent, cross-site device tracking mechanism that bypasses conventional browser privacy controls and is stable across networks, browsers, and privacy modes until device reboot.
• Predictability of Network Header Fields: Weaknesses in hash functions, PRNGs, and global counters enable the prediction of critical TCP/IP header fields such as timestamps, source ports, and ISNs, opening avenues for various network attacks.
• Importance of Cryptographic Primitives: The root causes of the vulnerabilities were traced back to weak hash functions, non-cryptographic PRNGs, and predictable ID generation schemes, highlighting the necessity of employing robust cryptographic primitives for all security-sensitive random number generation.
• Google Addressed Vulnerabilities: Google has implemented fixes in both Fuchsia and gVisor based on the researchers' recommendations, reinforcing the importance and impact of this security research.

About the Speaker(s)

Amit Klein is a researcher from the Hebrew University of Jerusalem, specifically affiliated with the School of Computer Science and Engineering. He presented this work at the NDSS Symposium, detailing a comprehensive security analysis of Google Fuchsia's and gVisor's network stacks, co-authored with Inon Kaplan and Ron Evan. His research interests evidently lie in network security, particularly in identifying systemic vulnerabilities within core operating system components and their implications for privacy and system integrity.