On Fri, Jul 18, 2008 at 09:56:45PM +0200, Goswin von Brederlow wrote:
See the latest DNS vulnerability about how you can compromise a clients DNS without having to hack a DNS server.
Thanks, I had heard of it. Note that you ignored the part about keeping it compromised. For this attack to be successful you need to keep the DNS wrong forever--you can't ever let an update slip through. That's a very different scenario then "hijack one session and you win".
Only way people notice a spoofed dns reply is when they saw a security update being announced and apt-get won't get it. Not everybody does, some people just run apt get and trust it to work.
Well, these things are announced for a reason. We can't protect people from themselves, and it's a long standing principle of debian security updates that running apt-get in a cron job is not a complete replacement for reading the advisories, for far more reasons than this single issue.
Bottom line: it's a network update across the internet--there will be ways to DOS the update. The best mitigation is to use diverse mechanisms to validate that your system has the updates you expect it to have. We've implemented that mitigation. Other proposed mitigations have their own issues (e.g., the "autosign the release in a cron job", which makes it *much* easier to sneak bad things in) or just move the goal posts a little bit (e.g., using https, which leads to questions about how we would validate the certs and simply changes what people would have to do to facilitate exactly the same attack ["we could use a CRL if the cert was compromised" "but what if I use a DNS trick to block the CRL check indefinitely?"].)
Mike Stone