[security] Predictable TXID can lead to response forgeries

[FiloSottile]

The default Id function uses math/rand, meaning the outputs are predictable, and an attacker might be able to use this to forge responses without being on path.

Seeding math/rand from crypto/rand is pointless, as the math/rand algorithm is invertible: given a sequence of outputs it's possible to reconstruct the Rand state and predict all future outputs. Exploitation might be a little slower because the outputs are just 16 bits, but it's likely to be possible.

Unless 0x20 or DNSSEC are used, response verification relies only on source port and TXID. They are both short, but the combination usually makes it hard for an off-path attacker to win the race against the real answer. Without the TXID, the attacker has a very good chance of success at a Kaminsky Attack.

A couple example scenarios:

• A DNS cache — the attacker makes a sequence of requests to get enough TXIDs to reverse the internal state of the RNG, then it causes a request to be issued by the cache to an upstream server, and knowing the TXID sends a spoofed answer to every port, poisoning the cache.
• A prober with an API, like say Let's Encrypt — the attacker causes a number of requests to its own domain to observe TXIDs, then causes a lookup for a target domain, and spoofs the response.

Since the performance cost seems negligible (#1037), I recommend doing the secure thing by default and just reading the 2 bytes from crypto/rand. If there are performance problems, just using a bufio.Reader should solve them, as most of the cost of crypto/rand is syscall overhead.

Filing publicly as asked by @miekg.

[jsha]

Thanks for filing this! I've sent a PR at #1044. Just for the public record: Let's Encrypt uses miekg/dns internally to communicate with our Unbound instances so I think this is not a vulnerability for us, but I do think it is worth fixing this issue by default for other software that uses this library.