现在的位置: 首页 > 综合 > 正文

最新dns漏洞相关

2013年11月02日 ⁄ 综合 ⁄ 共 2020字 ⁄ 字号 评论关闭

 All this DNS ...

I am taking a very brief break from my books to write a few thoughts about this entire DNS thing that everybody seems to be writing about. And reading all this, I can't help but feel like the only one in the room that doesn't understand the joke.

So Dan Kaminsky found a serious flaw in the implementation of the DNS protocol, apparently allowing DNS cache poisoning. This is good work.

I fail to understand the seriousness with which this bug is handled though. Anybody who uses the Internet has to assume that his gateway is owned. That is why we have SSL, that is why we have certificates, that is why SSH tells you when the host key changes. DNS can never be trusted - you always have to assume that your ISP's admin runs a broken filesharing server on the same box with BIND.

If it were legitimate to operate under the assumption that your gateway is not owned, you would not need SSH, or SSL. If I could operate under the assumption that my gateway wasn't owned, I could TELNET everywhere, and transmit my credit card details in the clear.

I am not saying that Dan's bug doesn't have utility for an attacker -- it's definitely more comfortable/less time consuming to do DNS poisoning than to own the gateway. But for the user, nothing changes, irrespective of whether the patch was applied or not. The basic assumption is always my gateway is controlled by my opponent.

I personally think we've seen much worse problems than this in living memory. I'd argue that the Debian Debacle was an order of magnitude (or two) worse, and I'd argue that OpenSSH bugs a few years back were worse.

So, let's calm down everybody. And I'd even argue that installing the patches is a lot less time-critical (for the user) than in most other scenarios. If you act under the assumption of "my gateway is owned", this should be no risk to you.

//

Use case:
1. User enters www.internetbank.com in the browser

2. Poisoned DNS returns attacking server

3. User does unencrypted login to attacking server which proxies to the TLS-protected internet-bank

4. You have MITM without the user noticing, even though the bank doesn't allow non-TLS connections

When this is done to the resolvers at a large ISP, lots of customers will be affected (since they in general won't check to see if their login is encrypted, perhaps they checked that the first time they used the bank).

If a single gateway device is owned, only you are affected. That is a huge difference.

抱歉!评论已关闭.