PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models

DNS FLaRE: A Flush-Reload Attack on DNS Forwarders

Speakers: Gilad Moav, Yehuda Afek, Anat Bremler-Barr (Tel Aviv University); Amit Klein (Hebrew University of Jerusalem)

Conference: USENIX Security

Paper page: https://www.usenix.org/conference/usenixsecurity25/presentation/moav

Paper PDF: https://www.usenix.org/system/files/usenixsecurity25-moav.pdf

(Note: This article is based on a peer-reviewed conference paper, not a recorded talk. There is no video transcript or timestamps available.)

Overview

In an era where digital footprints increasingly reveal personal information, the privacy of online browsing activity remains a critical concern. The paper "DNS FLaRE: A Flush-Reload Attack on DNS Forwarders" introduces a novel DNS cache-based timing side-channel attack that allows an attacker to accurately infer the specific times at which a user visits particular websites. Developed by researchers from Tel Aviv University and Hebrew University of Jerusalem, this sophisticated attack targets DNS forwarders, ubiquitous components of the DNS infrastructure found in most home routers and Linux systems (e.g., dnsmasq and systemd-resolved).

The significance of DNS FLaRE lies in its ability to bypass conventional browser-level privacy protections and expose sensitive browsing timelines, even when users employ privacy-enhancing modes like incognito. By exploiting subtle discrepancies in DNS resolution times—depending on whether a domain is present in the forwarder's cache—the attack can map a victim's online activity to specific time intervals. The threat model is remarkably minimal, requiring only that a victim be tricked into visiting a malicious website. This capability opens doors for highly targeted phishing attacks, IoT device detection and profiling, and raises profound privacy implications for individuals and entire households, as forwarder caches are often shared across all devices in a local network.

This paper is particularly noteworthy for being the first to demonstrate an attack that can expose the browsing activity of an entire household. Beyond traditional web browsing, DNS FLaRE extends its reach to Internet of Things (IoT) devices, allowing attackers to infer specific events or actions taking place within a smart home by observing the DNS queries made by these devices. The research not only details the attack methodology but also proposes several mitigation strategies, underscoring the need for enhanced privacy in private DNS infrastructure.

Background

The Domain Name System (DNS) is a foundational component of the internet, translating human-readable domain names (e.g., www.example.com) into machine-readable IP addresses. This process involves a hierarchical system of resolvers and caching mechanisms at various levels to reduce latency and optimize performance.

At the client end, a stub resolver initiates DNS queries. This component is typically embedded within operating systems or web browsers. While Windows stub resolvers include a DNS cache, standard Linux stub resolvers (like glibc) generally do not. Modern web browsers, notably Chromium-based browsers (Chrome, Edge, Opera) and Firefox, integrate their own stub resolvers, offering faster caching. To mitigate privacy risks from cross-site leaks, these browser caches employ Network State Partitioning, which isolates DNS responses based on the top-level site (origin). This means a DNS entry cached for youtube.com when visited via origin1.com would not be used if youtube.com is accessed via origin2.com. Chromium's built-in stub resolver also bypasses the OS stub resolver, a crucial detail for DNS FLaRE.

Upstream from the stub resolver is the DNS forwarder. A forwarder acts as an intermediary between local network clients and external recursive resolvers. Unlike recursive resolvers, which perform the full resolution process from root servers down, forwarders simply relay queries to an upstream recursive resolver and cache the responses. This lightweight design makes them ideal for low-end hardware, such as home routers. Two widely used DNS forwarding software solutions are dnsmasq and systemd-resolved. dnsmasq is prevalent in home routers from vendors like ASUS, D-Link, and NETGEAR, typically caching up to 150 DNS resource records (1000 on OpenWrt routers) using a Least Recently Used (LRU) eviction policy. systemd-resolved, found in popular Linux distributions like Ubuntu and Fedora, acts as a local DNS forwarder, caching up to 4,096 records and evicting entries with the shortest remaining Time-To-Live (TTL).

The next layer is the DNS recursive resolver, often operated by ISPs or public providers like Google DNS (8.8.8.8). If a requested domain is not in its cache, the recursive resolver queries the authoritative DNS hierarchy (root, TLD, and authoritative nameservers) to obtain the IP address, then caches and returns the result. Finally, authoritative nameservers hold the official, up-to-date DNS records for domain names.

DNS FLaRE is a cache-based timing side-channel attack, a class of attacks that exploit variations in the time it takes a system to perform operations, revealing sensitive information. These attacks are traditionally associated with hardware caches (e.g., CPU caches) and cryptographic operations. The paper adapts the Flush-Reload attack concept to the DNS cache. Introduced by Yarom et al. for CPU caches, Flush-Reload involves three stages:

1. Flush: The attacker clears a specific cache area.
2. Wait: The attacker waits for a fixed interval, during which a victim might access data that reloads the cache.
3. Reload: The attacker accesses the data and measures the access time. A fast access (cache hit) indicates the victim used the data, while a slow access (cache miss) suggests they did not.

Previous work by Felten et al. in 2000 explored "destructive" (one-time) DNS cache probing. DNS FLaRE significantly advances this by developing a full-fledged, repeatable side-channel attack to infer real-time website browsing activity, leveraging the shared nature and specific eviction policies of DNS forwarder caches.

Key Findings

The DNS FLaRE paper presents several key contributions that collectively enable its novel side-channel attack:

• DNS FLaRE Attack: The primary contribution is a new side-channel attack capable of determining whether a user has accessed a specific website within a defined time interval. This attack operates with a minimal threat model, requiring only that the victim visit a malicious website controlled by the attacker.
• Accurate Measurement of DNS Response Times: The authors propose a novel scheme to precisely measure DNS response times directly from a malicious website using JavaScript within the victim's browser. This technique bypasses existing browser limitations that prevent accurate cross-site DNS timing measurements, making it versatile for various DNS timing attacks, including geo-inference or user tracking.
• Efficient Cache Flushing: The paper extends prior work to develop an efficient method for flushing a forwarder's DNS cache. This is achieved using a small number of DNS requests issued by an attacker's script running in the victim's browser, effectively evicting existing entries to establish a known cache state.
• Bypassing Browser-Level DNS Caching: DNS FLaRE demonstrates how Network State Partitioning, a privacy feature designed to isolate browser DNS caches, can be paradoxically repurposed to enhance the attack's effectiveness. By rotating the origin of the malicious website, the attacker ensures that browser-level caching does not interfere with probing the forwarder's cache.
• Enhanced Website Classification through Multiple FQDNs: The attack's accuracy is significantly improved by leveraging websites that utilize multiple Fully Qualified Domain Names (FQDNs) for various services (e.g., CDNs, image servers, ad services). By collecting response times for each service's domain, attackers can create unique "website-specific domain fingerprints," leading to more precise classification of visited sites.
• IoT Operation Profiling: A critical extension of DNS FLaRE is its capability to accurately infer the timing of specific actions or events occurring on IoT devices. This is achieved by observing DNS resolution discrepancies for domains used by IoT devices from any computer within the same household, exploiting the shared nature of the forwarder's cache. For instance, the paper demonstrates detecting motion events from a security camera.
• Mitigation Strategies: The authors also outline several mitigation strategies to reduce the attack's effectiveness or likelihood, including browser-level defenses, limiting DNS response sizes, increasing cache capacities, and promoting the use of more common and shared DNS forwarders or recursive resolvers.

These contributions highlight a significant new privacy vulnerability within the widely deployed DNS infrastructure, particularly affecting home and small-office networks.

Technical Deep Dive

The DNS FLaRE attack operates in two main phases: a calibration phase and a continuous detection phase, structured into repeated detection cycles.

The calibration phase is crucial for establishing baseline timing distributions for cache hits and misses in the victim's environment. This involves repeating a sequence five times:

1. Flush: The forwarder cache is cleared.
2. Double Reload: Each target FQDN is reloaded once to measure a miss response time (as the cache was just flushed), and then reloaded again immediately to measure a hit response time.

These 10 measurements (5 misses, 5 hits) are used to train a Gaussian Naive Bayes classifier, which subsequently differentiates between cache hits and misses during the detection phase.

Each detection cycle then proceeds with four steps:

1. Flushing Step: The forwarder's cache is cleared of any FQDNs of interest. This ensures a clean slate, allowing the attacker to accurately detect subsequent user activity.
2. Sample Interval Step: A predetermined duration (e.g., 20 seconds) during which the attacker waits for the target user to potentially visit a tracked website.
3. Reloading Step: The attacker measures the access time of each FQDN of interest by issuing corresponding requests.
4. Classification Step: The collected timing data is fed into the pre-trained Gaussian Naive Bayes classifier to determine whether the target websites were accessed during the sample interval.

Efficient Cache Flushing

To flush the forwarder's cache, the attacker's JavaScript injects numerous "dummy" DNS entries. This is done by querying domain names controlled by the attacker, each configured to return many A/AAAA records. The goal is to exceed the forwarder's cache capacity, forcing the eviction of all legitimate entries.

• For dnsmasq on OpenWrt (1000 RRs cache), 1000 records are needed.
• For systemd-resolved (4096 RRs cache), 4096 records are needed.

The paper notes a practical constraint: BIND version 9.18.28 and later, often used by recursive resolvers upstream, defaults to limiting the accepted answer RRset size to 100 records per type. To ensure effectiveness, attackers may need to limit each DNS response to 100 A/AAAA records. This means 10 DNS queries are required to flush dnsmasq's cache and 41 for systemd-resolved's cache—still a relatively small number.

A key difference in flushing strategy arises from the eviction policies:

• dnsmasq uses an LRU policy. Flushing is straightforward by simply filling the cache.
• systemd-resolved evicts records with the shortest remaining TTLs first. To ensure the injected dummy records persist and evict legitimate entries, they must be assigned the maximum TTL of 7200 seconds (which systemd-resolved caps). Using lower TTLs could result in legitimate records (with longer remaining TTLs) surviving the flush.

While theoretically applicable to OS or browser caches, their significantly larger sizes make them much more challenging to flush compared to forwarders, which is why DNS FLaRE focuses on the latter.

Accurate DNS Response Time Measurement

The paper evaluates two techniques for measuring response times from within the victim's browser:

1. HTTP Resource Response Time: This involves measuring the total time to fetch an HTTP resource. However, this method includes TCP connection establishment, TLS handshake, and HTTP request/response times, introducing significant noise that obscures the distinction between a DNS cache hit and miss.

1. DNS Resolution Time (Port 0 Technique): This is the more accurate and preferred method. Browsers typically restrict direct access to DNS timing metrics (e.g., PerformanceResourceTiming API) for cross-origin requests due to privacy concerns. DNS FLaRE bypasses this by attempting to establish a TCP connection to a destination with port 0.

• When https://example.com:0/ is requested, the browser first must resolve example.com.
• Only after DNS resolution is complete does it attempt to connect() to the resolved IP address on port 0.
• On operating systems like Windows and macOS, connecting to port 0 is immediately flagged as invalid, raising an exception without attempting a full TCP handshake. This behavior allows precise measurement of only the DNS resolution time.

A nuance of the port 0 technique is that modern browsers also issue an HTTPS DNS record query (e.g., _0._https.example.com) in addition to A/AAAA records. This extra lookup can introduce noise. To mitigate this, the attacker prefetches the HTTPS record by initiating a request to the prefixed FQDN (e.g., https://_0._https.example.com/). This causes the (negative) HTTPS record response to be cached by the forwarder, ensuring it's available promptly during the actual measurement.

This "port 0 technique" works on Chrome and other Chromium-based browsers, as well as Safari, on Windows and macOS. Firefox is incompatible (blocks port 0), and Linux allows connection attempts to port 0, preventing immediate failure and thus accurate DNS timing isolation.

Bypassing Browser-Level DNS Caching with Network State Partitioning

A critical challenge for a continuous timing attack is the browser's own DNS cache. If the browser caches a DNS response, subsequent requests would be served from this cache, bypassing the forwarder and rendering the attack ineffective for the duration of the TTL. DNS FLaRE cleverly repurposes the browser's Network State Partitioning mechanism.

• This mechanism isolates DNS caches based on the top-level origin.
• By rotating the origin of the malicious website (e.g., attacker1.com, attacker2.com, etc.) for each measurement, the attacker ensures that the browser's DNS cache is bypassed. Each new origin creates a new partition key, forcing the browser to issue a fresh DNS query that hits the forwarder.
• The number of attacker-controlled domains required depends on the calibration samples, maximum TTL, and measurement interval. For example, 10 calibration samples, 400s max TTL, and 20s interval require 20 domains. This is considered a low-cost requirement.

Chromium's built-in stub resolver also bypasses the OS-level DNS cache, making Chromium-based browsers ideal targets. For Firefox on Linux, the attack remains viable because Linux stub resolvers generally lack caching, and users either rely on systemd-resolved or dnsmasq in their home network.

Enhanced Website Classification

To improve classification accuracy, DNS FLaRE leverages the fact that most websites load resources from multiple FQDNs (e.g., www.example.com, images.example.com, scripts.example.com).

• By identifying a list of FQDNs unique to a target website, the attacker can create a more robust "domain fingerprint."
• Measuring response times for all these associated FQDNs provides more features for the classifier.
• A Gaussian Naive Bayes classifier is used, chosen for its suitability with the near-normal distribution of response times. Experiments also showed comparable accuracy with linear classifiers and decision trees.

Demo / Proof of Concept

To demonstrate the practical feasibility of DNS FLaRE, the researchers developed a proof-of-concept (PoC) implementation. This PoC validated the ability to infer web browsing activity by exploiting DNS resolution time discrepancies.

The PoC was implemented using Flask in Python, a common web framework. For target websites, www.youtube.com and www.facebook.com were selected, given their high popularity. The experimental setup involved a forwarder configured to work with a nation-wide ISP's recursive resolver.

The attack was configured with a sample interval of 10 seconds, meaning the attacker checked for website visits every 10 seconds. Twenty iterations of the attack were conducted for each combination of operating system, browser, and target website. In half of these iterations (10), the target website was actively accessed by the user, while in the other half, it was not. The effectiveness of the PoC was then evaluated by calculating the classification accuracy based on these 20 iterations.

The PoC results closely mirrored the broader experimental findings presented in the paper, demonstrating both the effectiveness and practicality of the attack across various configurations:

| OS | Browser | Website | Accuracy (HTTP Resource Response Time with Multiple FQDNs) [%] | Accuracy (DNS Resolution Time with Primary FQDN) [%] |

| :-------- | :---------- | :-------- | :------------------------------------------------------------- | :--------------------------------------------------- |

| Windows | Chrome | Youtube | 70 | 95 |

| | | Facebook | 65 | 100 |

| | Microsoft Edge | Youtube | 75 | 90 |

| | | Facebook | 55 | 95 |

| | Opera | Youtube | 70 | 90 |

| | | Facebook | 55 | 95 |

| macOS | Chrome | Youtube | 75 | 95 |

| | | Facebook | 70 | 85 |

| Debian (dnsmasq) | Chromium | Youtube | 60 | N/A* |

| | | Facebook | 50 | N/A* |

Note: "N/A" for Debian/Linux using "DNS Resolution Time" indicates that the port 0 technique for direct DNS resolution time measurement does not work on Linux, as explained in the Technical Deep Dive section.

These results clearly illustrate that the "DNS Resolution Time with Primary FQDN" scheme, when applicable, consistently achieved very high accuracy (e.g., 95% for YouTube on Windows Chrome, 100% for Facebook on Windows Chrome). Even where the more accurate DNS resolution time was unavailable (e.g., Linux), the "HTTP Resource Response Time with Multiple FQDNs" scheme still provided reasonable, albeit lower, classification accuracy. The PoC successfully validated the core claims of DNS FLaRE, reinforcing its real-world applicability for inferring browsing activity.

Defensive Implications

The DNS FLaRE attack highlights significant privacy vulnerabilities in widely deployed DNS forwarders, necessitating robust defensive strategies. The paper proposes several mitigations, while also identifying non-mitigating approaches.

Proposed Mitigations

1. Blocking Port 0 on the Browser Level: The most accurate measurement technique in DNS FLaRE relies on exploiting the connect() call to port 0 to isolate DNS resolution time. Browsers could implement a policy to block the use of port 0 prior to DNS resolution. This would prevent the attacker from obtaining highly accurate DNS timing measurements. However, this is a partial mitigation, as the less accurate "HTTP resource response time with multiple FQDNs" scheme could still be exploited, albeit with reduced effectiveness.
2. Bounding DNS Response Size: The cache flushing mechanism in DNS FLaRE relies on injecting a large number of A/AAAA records to fill the forwarder's cache. An analysis of the top 1 million domains revealed that over 99% have at most five A records, and only 108 domains have more than 20 A records. Forwarders could enforce a bound on the number of A records in a response (e.g., limiting to 5 or 10). While not a fundamental fix, this would significantly increase the effort required for an attacker to flush the cache, potentially requiring many more queries and thus more time, making the attack less efficient.
3. Larger Cache Sizes: Increasing the size of a forwarder's cache would make it harder to flush, as more records would need to be injected. However, this mitigation is often impractical for home routers and other low-end hardware, which are designed to be cost-effective with limited memory and processing power.
4. Using Common and Shared DNS Resolvers/Forwarders: When users opt for widely shared DNS resolvers (e.g., Google DNS, Cloudflare DNS) or forwarders, the DNS out-of-browser cache involved is shared among a much larger user base. This increased sharing "dilutes" the association between cache entries and any individual user's activity, making it harder for an attacker to correlate cache state changes with a specific victim's browsing behavior. This mitigation is less applicable in environments like corporate networks where external resolvers might be restricted.

Non-Mitigations

The paper also clarifies that certain widely adopted DNS security protocols do not mitigate DNS FLaRE:

• DNS over HTTPS (DoH): While DoH encrypts DNS traffic between the client and the DNS server, it does not alter the caching behavior of the DNS forwarder or resolver. Therefore, cache-based attacks like DNS FLaRE remain unaffected as long as the DoH destination is a vulnerable forwarder. It's noted, however, that DoH is often used with "common and shared DNS resolvers," which does provide some protection via the "dilution" effect described above.
• DNSSEC: DNSSEC ensures the authenticity and integrity of DNS responses through cryptographic validation. However, it offers no protection against timing side-channel attacks that exploit cache hit/miss discrepancies, as it doesn't change how caching itself operates.

Other Considerations

• Uncachable HTTPS RRs: The paper identified instances where certain domains (e.g., slack.com) returned HTTPS-prefixed queries (e.g., _0._https) with only authority or CNAME RRs, lacking A/AAAA records. This behavior caused dnsmasq to skip caching the result, nullifying the benefits of prefetching and reducing accuracy for those domains.
• High DNS Traffic: In households with exceptionally high legitimate DNS traffic, the forwarder's cache might be naturally evicted frequently, posing a challenge for DNS FLaRE. However, an attacker could potentially counter this by reducing the sample interval, maintaining more control over the cache state.
• Sample Interval vs. TTL: A limitation arises if the sample interval is longer than the TTL of a target FQDN. If a record is cached but its TTL expires before the reload step, it could lead to false negatives. This is exacerbated by stale records cached upstream. While false negatives are less critical than false positives in this threat model, they represent a reduction in detection reliability.
• Victim Activity during Calibration: If the victim continuously accesses the targeted website during the attack's calibration phase, it could interfere with the accuracy of the calibration process, compromising the correctness of the hit/miss distinction.

Ultimately, the paper concludes that private DNS infrastructure, particularly DNS forwarders, introduces significant privacy risks that require dedicated efforts to enhance user privacy beyond current measures.

Key Takeaways

• DNS FLaRE is a novel timing side-channel attack that exploits DNS forwarder caches (dnsmasq, systemd-resolved) to infer a victim's website browsing activity with high temporal accuracy.
• Minimal Threat Model, Broad Impact: The attack only requires the victim to visit a malicious website and can reveal browsing activity for an entire household due to the shared nature of forwarder caches.
• Accurate DNS Timing Achieved by "Port 0 Trick": The attack bypasses browser privacy restrictions on DNS timing by attempting to connect to port 0, isolating DNS resolution time measurements on Windows and macOS.
• Network State Partitioning Repurposed: A browser privacy feature designed to partition DNS caches is exploited by rotating attacker-controlled origins, ensuring the attack consistently probes the forwarder's cache.
• IoT Device Profiling: DNS FLaRE can detect specific events or operations on IoT devices (e.g., motion detection from a security camera) by observing their unique DNS query patterns from another device in the same household.
• Standard DNS Security Protocols Are Insufficient: DoH and DNSSEC do not inherently mitigate this attack, as they do not alter the underlying caching behaviors that DNS FLaRE exploits. Mitigations require specific changes to browser behavior or forwarder configurations.

About the Speaker(s)

The research paper "DNS FLaRE: A Flush-Reload Attack on DNS Forwarders" was authored by Gilad Moav, Yehuda Afek, and Anat Bremler-Barr from Tel Aviv University, and Amit Klein from Hebrew University of Jerusalem. The authors are affiliated with academic institutions, indicating their expertise in network security, privacy, and side-channel attack research within a university setting. Their collective work on DNS FLaRE contributes to the ongoing discourse on enhancing user privacy and understanding vulnerabilities in critical internet infrastructure.