The trust-dns-proto library contains the underpinning DNS protocol implementations, including the serialization and deserialization primitives for names and labels, where a name is
www.example.com and a label is
www. DNS being a space conscious protocol has always had a name/label compression technique for sticking references back to previously written names/labels in a packet to reduce the DNS packet size.
The deserialization code has a bug related to this in which the reference to another name/label in the packet would be trusted in such a way that a malicious packet could cause a stackoverflow.
All versions of trust-dns-resolver, trust-dns and trust-dns-server are affected. This has been fixed in the current release of trust-dns-proto 0.4.3, which aligns with the trust-dns-resolver 0.9 release, as well as trust-dns (client) and trust-dns-server 0.14 series.
The corresponding fix in the alpha series is trust-dns-proto 0.5.0-alpha.3, which is used in trust-dns-resolver 0.10.0-alpha, as well as trust-dns (client) and trust-dns-server 0.15.0-alpha series.
A huge thanks goes to @oherrala who found and reported this issue, as well as reviewed and even patched the initial fix. I’m very grateful to his excellent work and detailed report on the issue.
Link to the rustsec advisory: https://github.com/RustSec/advisory-db/pull/62
EDIT: To make this clear, this is a DoS potential mainly effecting the trust-dns-server, and much more difficult to target the resolver and client (requiring a MITM, man-in-the-middle targeted attack). The result is a crash, with no known memory visibility issues.
As an addendum to this issue: I’m now aware that we currently don’t have a decent process for reporting security advisories in the trust-dns project. I’m going to be researching a process for both reporting issues, and coordinating responses to issues with an early alert system to notify potentially impacted projects. This was a good learning exercise for the project. If anyone has a decent process they’re aware of and can point me to it, I would appreciate it.