Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign up[security] Predictable TXID can lead to response forgeries #1043
Comments
jsha
added a commit
to jsha/dns
that referenced
this issue
Dec 5, 2019
Fixes miekg#1043 and miekg#1037
This comment has been minimized.
This comment has been minimized.
|
Thanks for filing this! I've sent a PR at #1044. Just for the public record: Let's Encrypt uses |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The default
Idfunction 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
Randstate 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:
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.Readershould solve them, as most of the cost of crypto/rand is syscall overhead.Filing publicly as asked by @miekg.