Skip to content

Vulnerability in trust-dns and trust-dns-server (Part 2) #1705

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions crates/trust-dns/RUSTSEC-0000-0000.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
```toml
[advisory]
id = "RUSTSEC-0000-0000"
package = "trust-dns"
date = "2023-06-01"
url = "https://github.com/bluejekyll/trust-dns/pull/1952"
categories = ["denial-of-service"]
keywords = ["packet loop"]

[versions]
patched = ["^0.22.1", ">=0.23.0-alpha.3"]
```

# Remote Attackers can cause Denial-of-Service (packet loops) with crafted DNS packets

trust-dns and trust-dns-server are vulnerable to remotely triggered denial-of-service attacks, consuming both network and CPU resources.
DNS messages with the QR=1 bit set are responded to with a `FormErr` response.
This allows creating a traffic loop, in which these `FormErr` responses are sent nonstop between vulnerable servers.

There are two scenarios how this can be exploited: 1) Create a loop between two instances of trust-dns, consuming network resources, or 2) consuming the CPU of a single instance.

With two instances *A* and *B* an attacker sends a DNS query with a spoofed source IP address to *A*.
*A* replies with a `FormErr` to *B*.
Now both servers with ping-pong the message back and forth until by chance the packet is dropped in the network.
Multiple spoofed packets can be sent by the attacker, increasing resource consumption.

A single server can get locked up replying to itself.
Same setup as above, but now *A* sends the reply to itself.
The packet is sent out as fast as the CPU and network stack manage.
This locks up a CPU core.
Multiple packets from the attacker consume multiple CPU cores.