2008-09-15 00:46:58

CVE-2008-1447 is still alive - DNSSEC the only way out

With a lot of noise, Dan Kaminsky released the security flaw in the DNS protocol now known as CVE-2008-1447.

The vulnerability is basically a lack of entropy in the XIDs which are used to differenciate between the different responses and to associate them with the corresponding queries. The DNS protocol allows additional information to be submitted in a response which was not asked for, for example if a CNAME is resolved, the corresponding A record which is pointed to may be returned in an additional section. This record is then learned by the DNS resolvers and will be returned on the next request, instead of querying the servers again.

Since the XIDs are rather short, an attacker can send DNS responses with various XIDs in order to poison the DNS cache with arbitrary information. Hosts querying the poisoned host names during the TTL will then receive the fake record and connect to an entirely wrong server.

All my useless advice

Back in 2003, Dan Bernstein already published information about the vulnerability, only making slightly less noise than Kaminsky. According to his assessment, and to public perception, the port randomization performed by DJBDNS already protected against the poisoning attack. Thus, the ISC released a new bind version 9.5.0-P2 which also introduced port randomization, causing all of the various NAT problems already known from the FTP.

However, shortly thereafter, someone put up to actually calculate the odds of the attack with port randomization, and found that the birthday paradoxon actually decreased the complexity of the attack significantly. Shortly thereafter, an exploit for port randomized DNS was released, showing that the port randomization was not a solution to the problem. This leaves DJBDNS vulnerable, too.

DNSSEC – the only way out?

Apparently, only one solution is available so far which really solves the problem: the DNS security extension DNSSEC (RFC4034). DNSSEC signs the zone with SHA1 and an RSA key. The complexity of forging this signature is significantly higher.

The disadvantage of DNSSEC is that all zones must be re-signed either on update (not so problematic) or every 30 days (harder to implement), or otherwise their content will be lost until a new signature is generated. Once one manages to automate this step, however, DNSSEC is really useful.

The ISC has prepared a little guide to help people implementing DNSSEC in 6 minutes – and that's already all that's required. However, DJB hates DNSSEC due to the amout of CPU time used to verify the signature, and thus did not implement it. Salvation can probably be achieved by creating a DNSSEC signed zone and converting it to a djbdns zone using the zone conversion tool.

PowerDNS also supports storage of DNSSEC records, but cannot create them or sign zones in any way. The only way to achieve it is again to sign a bind zone and to convert it. The same applies to MaraDNS: there are simply no DNSSEC tools available.

Spreading the FUD

Nevertheless, various sources are still suggesting that DNSSEC does not help to prevent the attack, and that only source port randomization yielded salvation. Surely, source port randomization does increase the resilience to the attack, but the problem remains unresolved.

Only DNSSEC can provide a definitive solution to the spoofing attacks. Currently, the lack of a trust infrastructure still reduces this protection, since only the host record and the zone signature must be spoofed – which is however already far from feasible.

At the same time, people should stop repeating things which a single source told them – be it Dan Bernstein or Linus Torvalds. No matter if these people are idols, their competence is not universal.

Posted by Tonnerre Lombard | Permanent link | File under: security, network