GHSA-XVG2-CGV6-6H7V: Local Traffic Interception and Information Disclosure via Improper DNS Block Responses in netfoil

The Go-based minimal DNS proxy netfoil provides domain-level filtering to block trackers, ads, and malicious sites. Prior to version 0.4.0, the proxy failed to implement secure domain blocking mechanics, leading to a severe protection mechanism failure classified under CWE-693.\n\nInstead of returning a standard Non-Existent Domain (NXDOMAIN) status, netfoil returned a successful NOERROR DNS response containing dummy A, AAAA, or HTTPS records. These dummy records resolved to null IP addresses (0.0.0.0 or ::), signaling to the querying application that the domain was active and reachable.\n\nThis behavior exposes clients, especially those on Linux platforms, to local traffic interception. When client applications attempt to connect to the resolved null IPs, the OS kernel routes the requests back to the local loopback interface (localhost). Consequently, any unprivileged local process listening on the target ports can intercept sensitive transaction details, including session cookies and authorization tokens, originally intended for the blocked external domain.

The root cause of the vulnerability lies in the implementation of the generateBlockResponse function within dns/filter.go. Instead of dropping the query or returning an error status, the function explicitly constructed a DNS answer containing an active resource record pointing to ipv4Null (0.0.0.0) or ipv6Null (::) and marked the response header flags with ResponseCodeNoError.\n\nWhen a client operating system receives this response, the local resolver interprets it as a fully valid, successful domain resolution. On Linux platforms, the kernel's routing table treats connections to 0.0.0.0 or :: as aliases for the loopback address (127.0.0.1 or ::1). Therefore, instead of terminating the connection attempt or generating a connection-refused error, the client browser or application initiates a three-way TCP handshake with localhost.\n\nThis design flaw introduces a severe vulnerability when local services run on matching ports (e.g., 80 or 443). Because the client browser believes it is communicating with the legitimate external host (for example, analytics.company.com), it transmits standard HTTP headers, cookies, and tokens over this loopback connection. An unprivileged local daemon or web server can accept these connections and capture high-value credentials.

The vulnerable version of dns/filter.go constructed the blocked response by setting the RCODE to ResponseCodeNoError and appending dummy IPv4 and IPv6 null values in the answers slice:\n\ngo\n// Vulnerable Implementation\nfunc generateBlockResponse(question Question) *Response {\n\tdomain := question.Name\n\trecordType := question.Type\n\n\tvar response *Response\n\tflags := Flags{\n\t\tRCODE: ResponseCodeNoError, // ERROR: Signals successful resolution\n\t}\n\n\tif recordType == RecordTypeA || recordType == RecordTypeAAAA {\n\t response = &Response{\n\t Flags: flags,\n\t Answers: []Answer{\n\t {\n\t Name: domain,\n\t Type: recordType,\n\t Class: ClassTypeIN,\n\t TTL: defaultTTL,\n\t IPv4: ipv4Null, // 0.0.0.0\n\t IPv6: ipv6Null, // ::\n\t },\n\t },\n\t }\n\t} // ... HTTPS record logic also used ipv4Null / ipv6Null\n\n\nIn version 0.4.0, the package was refactored to remove the creation of synthetic resource records entirely. The updated logic changes the response code to ResponseCodeNXDomain and sets the answers to nil:\n\ngo\n// Patched Implementation in Commit 891d3513c77999a9deef9f23506807d9653ee448\nfunc generateBlockResponse() *Response {\n\tvar response *Response\n\tflags := Flags{\n\t\tRCODE: ResponseCodeNXDomain, // FIX: Informs client the domain does not exist\n\t}\n\n\tresponse = &Response{\n\t Flags: flags,\n\t Answers: nil, // FIX: Empty answer block forces connection failure\n\t}\n\n\treturn response\n}\n\n\nThis patch completely eliminates the routing of blocked requests to localhost. The client's operating system resolver instantly aborts connection attempts when encountering an NXDOMAIN response code, ensuring that no local ports are contacted.

Exploitation of GHSA-XVG2-CGV6-6H7V is straightforward and requires no active privileges or authentication. Below is a representation of the routing flow during an exploitation attempt:\n\nmermaid\ngraph LR\n Client["Client App / Browser"] -->|"1. Query: tracker.com"| Proxy["Vulnerable netfoil"]\n Proxy -->|"2. Response: 0.0.0.0 (NoError)"| Client\n Client -->|"3. TCP Handshake to 0.0.0.0:80"| Kernel["Linux Kernel Routing"]\n Kernel -->|"4. Redirects connection"| Localhost["Local Listener (Port 80/443)"]\n\n\nAn attacker operating on the same machine as the victim (e.g., in a multi-user environment or via a malicious low-privilege script) can bind to the target port on localhost (such as 8080 or 80). When the victim's application triggers a background request to a blocked tracker, netfoil resolves the domain to 0.0.0.0, routing the traffic directly into the attacker's listener.\n\nOnce connected, the victim's client transmits a fully populated HTTP request. Since the client thinks it is communicating with the legitimate domain, the request includes active Session IDs, Bearer tokens, and Authorization headers. The attacker can log these headers to hijack sessions or gain unauthorized API access.

The security impact of this vulnerability is significant, particularly in development, corporate, or shared Linux environments where netfoil is deployed. By resolving blocked domains to local loopback addresses, the proxy undermines the security isolation between external web services and local applications.\n\nFurthermore, this flaw enables Same-Origin Policy (SOP) bypasses. Because the browser continues to map the domain name to the request, cookies scoped to the blocked domain are transmitted to localhost, allowing local malicious pages or applications to execute Cross-Site Request Forgery (CSRF) or Server-Side Request Forgery (SSRF) actions against services running on the loopback interface.\n\nThe CVSS v4.0 score is assessed at 7.4 (High), reflecting high confidentiality and integrity impacts on the affected host, with a low attack complexity. Although exploitation relies on specific local state conditions, the automated nature of modern web browsers makes exploitation highly reliable once those conditions are met.

To remediate this issue, administrators and developers must upgrade netfoil to version 0.4.0 or later. This version incorporates the correct NXDOMAIN behavior, which stops DNS resolution on the client side without executing local loops.\n\nIf upgrading is not immediately possible, temporary mitigation can be achieved by overriding local routing behaviors or applying local firewall policies. Specifically, rules can be created using iptables or nftables to drop outgoing packets destined to 0.0.0.0 or :: that are not originating from local control interfaces.\n\nAnalysis of the patch confirms that the fix is complete. By shifting from dummy address spoofing to standard NXDOMAIN responses, the root cause—relying on invalid/routable address translation—is fully eradicated, ensuring that variant attacks utilizing alternative local loopback ranges are blocked.