Nardol

I am following closely this new DNS mess. In fact, there’s nothing really new in that. DNS has been attacked lots of times over the years – as a result of not being designed with security in mind from the ground up -, just this new one is a combination of known attacks against known security flaws. The “quick fix” is not a real fix, and just incorporate old ideas into the most used DNS software, strengthening it to face the attack. The details leaked, and there’s already at least one public exploit (and who knows how many in the wild).

The new buzzword is DNSSEC.

I don’t like DNSSEC. I never did. The first time I heard of it, around year 2001, it was a centralization of a decentralized database: A proposed company (called Network Solutions) would serve as a central authority, signing every root DNS entry. It was a joke! Come on! DNS is suppose to be decentralized! Having a central company anywhere is just a huge step back in decentralization (not to mention a huge step back in security).

Time passed, and the DNSSEC specs evolved to a more decentralized way of thinking. The state it is now, and the implementations we saw so far are not good. No! I am not talking about security… I am talking about the KISS principle: DNSSEC turns something really simple to deploy into a full-time job, with frequent key roll-overs and re-signing everytime you change the zone – a huge mess! Yes, there are automated tools, but, come on! you still have to wait for TTL to expire before publishing this part or that part of the cryptographic machinery… And, if we are talking about real security, are we going to build some automated tool “fire-and-forget”-style and not follow it? If we are not looking at it as it goes, and it fails, we could end up with a completely wrong set-up or (even worse) a non-validating zone.

And I haven’t yet mentioned the increase in payload… I am not completely convinced that this alone would not lead to DoS attacks just by compromising the responsiveness of the servers (and DoS attacks are already available for quite some time – maybe the DNSSEC-medicine is worse than the disease…). The root (”.”) servers are not even DNSSEC-aware, and there’s a whole class of other stuff to work-around the fact that they may not be DNSSEC-aware for quite some time yet.

There has to be a simpler way!

I can imagine at least three ways to fix the problem until we can fix DNS in a KISS way… And they’re all KISS also:

• Change Transaction ID field. This is the first Achiles heel of this crisis. Let’s increase the length of this field to 2048 bits, or even larger. Better yet, let’s make it variable, so every system administrator can set his servers’ own size. Yes, I know this leads to replacing ALL the DNS infrastructure, but isn’t that what we are doing right now, anyway?

• Deactivate in-bailiwick injection. Over the years, DNS have been expanded to allow a lot of things other than translation of names into numbers (or to ease this translation). The second Achiles heel is the ability to inject the IP address for WWW.VICTIM.COM while consulting for 10294DKGJSDL.VICTIM.COM since both name-addresses are in the same bailiwick (in-bailiwick). Let’s take a step back, and deactivate all this… Before 1995, the same thing could happen with any addresses, including those “out of bailiwick”, and it was fixed to only allow those in-bailiwick… Let’s fix it again to not allow it at all!

• Good, and old iptables. Couldn’t we just use iptables’ LIMITS to stop this attack and blacklist the attacker? We’ve been doing this for a lot of other things (SYN-floods, ICMP attacks, etc). Can’t we just do the same. Again: this is not a new thing… it relies on multiple attacks in a short period of time, just like other attacks we’ve seen and successfully blocked with these techniques…

Maybe some of those three solutions are flawed… Maybe none are flawed and can be deployed together… Maybe I am wrong and DNSSEC is the only way to go… But let’s not panic, let’s cool our minds and begin thinking it through. I still don’t think DNSSEC is the holy grail…

Now… I already spent more time than intended on this… let me go back signing some zones ;-)

Debian 4.0 version of Ruby is open to the, now widely known, Ruby security vulnerabilities. The bug is reported as 487238 in Debian’s BTS, and is closed, since the version now in sid (version 1.8.7.22-1) is already fixed. Users of stable can apply the patch provided by Daniel Franke (it doesn’t seem to fix all, but goes a long way).

Apparently, this brought up (again) the rants over full disclosure. Indeed, what is vulnerable is not that hard to find, as Zed Shaw showed us, so, why not talk about it in a plain and bold form? Why just provide the CVE numbers and ask for everybody to upgrade? Zed goes more deep about the quality of C code, but that is not the issue I want to talk about…

As a Free and Open Source Software supporter (and developer), I can see the benefits of full disclosure. As a not-full-time webmaster, I can see the benefits of not having a “proof-of-concept” piece of code attached to the vulnerability report. Of course, there’s a lot of things a webmaster can do to prevent having a machine completely compromised in case a security advisory is published with a proof-of-concept code in it (think about chrooting, randomized memory protection, security libraries, grsecurity, SELinux, etc) – and my machines, although vulnerable to the bug, would not be fully compromised if exploited.

I guess one should be prepared to whatever comes from the Internet… Full disclosure, in this sense, have more pros than cons, IMHO. For instance it was not clear if Debian 4.0 were vulnerable… There were no security advisory coming from Debian (and there’s still not), and it is not promptly obvious if the version packaged is affected. I know that at least I wanted to run a proof-of-concept to check if my server is vulnerable or not before going all the way into packaging a fix (or backporting the sid version), and it was not until I read Matasano Chargen Blog that I could test older versions. But different people have different ideas…