Memory exhaustion from an unchecked SSH packet length

When reading a packet, russh took the 4-byte packet length sent by the peer and sized its receive buffer from it without any upper bound. The length is fully controlled by the other side of the connection and is read before authentication, so an unauthenticated client can claim packets of up to...

Recursor followed every glueless name server in a referral (no fixed hickory-recursor release)

For referrals whose name servers are outside the delegated zone and come without glue, the recursor resolved every listed name server, with no cap on referral width and no per-query work budget. Someone who controls a zone can use this to make each client query send a large number of queries to a...

Unbounded retries on truncated responses in the name server pool

When an upstream answer had the TC truncated bit set, the resolver's name server pool disabled UDP and sent the query again. It did this for every truncated answer, including answers that already came over TCP, and it kept no count of retries. A name server that sets TC on every answer, which...

Inverted NSEC3 comparison lets one record "prove" that almost any name does not exist

When DNSSEC validation looks for the NSEC3 record that covers a hashed name, the last record in the zone's hash chain needs special handling, because its next hashed owner name sorts before its own hash. For that record the two comparisons were reversed: it was treated as covering every hash belo...

`Resolver::lookup` and `lookup_ip` returned records that failed DNSSEC validation

With DNSSEC validation enabled, Resolver::lookup and Resolver::lookupip returned Ok with the records even when validation found the response bogus. The result was only visible in each record's proof status, which callers had to inspect themselves. Applications that enable validation and treat a...

DNSSEC validation cache could reuse an Insecure result for a different name

The DNSSEC validation cache used a 64-bit hash of the query as its key, and two keys with the same hash counted as equal. The Hash implementation of Name hashed the bytes of the labels but not where one label ends and the next begins, so names that differ only in the placement of dots such as ab....

Spoofed malformed UDP datagrams abort DNS lookups

While waiting for a reply on a UDP connection, the client parsed every datagram that arrived from the name server's address and port before checking its message ID. If parsing failed, the attempt ended with an error instead of dropping the datagram and waiting for the real reply. The receive loop...

NSEC3 records from another zone were accepted in proofs of nonexistence

When DNSSEC validation used NSEC3 records to prove that a name or record type does not exist, it compared only the hashed first label of each NSEC3 owner name with the hash of the name being checked. The rest of the owner name, which says which zone the record belongs to, was not checked. Someone...

Recursor kept querying cyclic glueless sibling delegations

Two zones can each delegate to name servers named only inside the other zone, with no glue records the cyclic sibling case in RFC 9471 section 2.3. Such delegations can never be resolved, but the recursor did not stop when it came back to a zone it was already resolving. It kept sending queries...

DNSSEC validation accepted an unrelated signed RRset as the answer (hickory-proto)

Up to 0.26.0-alpha.1, hickory-proto's DNSSEC validation treated a response with a non-empty answer section as a positive answer if its records validated, without checking that any of them matched the queried name and type. Someone who can answer or modify DNS responses could return a genuine sign...

DNSSEC validation accepted a validly signed but unrelated RRset as the answer

When a response had a non-empty answer section, DNSSEC validation treated it as a positive answer as long as the records in it validated. It did not check that any of those records had the queried name and either the queried type or type CNAME. An attacker who can answer or modify DNS responses c...

NSEC3 owner names not checked against the zone in DNSSEC validation (hickory-proto)

Up to 0.26.0-alpha.1, hickory-proto's DNSSEC validation matched NSEC3 records to a name only by the hashed first label of the NSEC3 owner name, without checking that the rest of the owner name was the zone in question. A signed NSEC3 record from any zone the attacker controls could therefore be...

RRSIG signer name was not checked against the zone of the signed records

DNSSEC validation checked an RRset against the DNSKEYs of whatever zone was named in the RRSIG's Signer's Name field. RFC 4035 section 5.3.1 requires that name to be the zone that contains the RRset, but this was not checked. Anyone who controls a DNSSEC-signed zone, and can answer or modify DNS...

Recursor followed every glueless name server in a referral, with no per-query budget

When a referral listed name servers outside the delegated zone and gave no glue addresses, the recursor looked up A and AAAA records for every listed name server, recursing into each one. Only the chain-depth limits applied. There was no cap on how many name servers it chased per referral or on t...

Recursor kept querying cyclic glueless sibling delegations (no fixed hickory-recursor release)

Two zones can each delegate to name servers named only inside the other zone, with no glue records RFC 9471 section 2.3. The recursor did not stop when it came back to a zone it was already resolving, so someone who controls two such zones can make it send many upstream queries for each client...

NXDOMAIN accepted for a proven empty non-terminal (hickory-proto)

Up to 0.26.0-alpha.1, hickory-proto's NSEC validation accepted an NXDOMAIN response as secure even when the covering NSEC record's next domain name was below the queried name, which proves the name exists as an empty non-terminal. Because the response code is not signed, someone who can modify DN...

NXDOMAIN accepted for an empty non-terminal that the NSEC record proves exists

When an NSEC record's next domain name is below the queried name, the queried name exists as an empty non-terminal RFC 8020 section 3.1. The NSEC validator did not check for this case and accepted an NXDOMAIN response backed by such a record as secure. The response code is not covered by any...

Inverted NSEC3 comparison in DNSSEC validation (hickory-proto 0.25)

In hickory-proto 0.25.0 through 0.26.0-alpha.1, DNSSEC validation handled the last NSEC3 record of a zone's hash chain with its two comparisons reversed. That record was treated as covering almost every hash it does not cover, so an attacker who can answer or modify DNS responses could replay it,...

NSEC wraparound detection trusted an unvalidated SOA record

The last NSEC record in a zone points back to the zone apex. To recognise it, DNSSEC validation treated an NSEC record as covering every name after its owner when its next domain name equalled the owner name of an SOA record in the response. That SOA record did not have to pass validation. An...

Buffer overflow with AES key wrap with padding in `cipher_update_inplace`

CipherCtxRef::cipherupdateinplace had the same sizing error that 0.10.79 fixed in cipherupdate GHSA-xv59-967r-8726; that fix missed this method. It required room for inlen + blocksize bytes, but with the AES key-wrap-with-padding ciphers OpenSSL writes up to 7 more bytes when inlen is not a...

Buffer overflow in `Deriver::derive` and `PkeyCtxRef::derive` with OpenSSL 1.1.x

Deriver::derive and PkeyCtxRef::derive pass the length of the caller's buffer to EVPPKEYderive and rely on OpenSSL to write no more than that. With OpenSSL 1.1.x, the X25519, X448 and HKDF-extract implementations ignore the length they are given and always write the whole result, so a buffer...