最新dns漏洞相关
来源:互联网 发布:微软windows下载 编辑:程序博客网 时间:2024/05/16 00:49
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.
- 最新dns漏洞相关
- DNS服务器漏洞
- DNS漏洞攻击代码
- DNS域传输漏洞
- DNS域传送漏洞
- DNS域传送漏洞
- DNS 相关
- 最新DNS病毒问题
- 最新远程溢出漏洞
- dedecms最新注入漏洞
- emseasy最新注入漏洞
- CTSCMS 最新漏洞
- Struts最新漏洞
- struts2 最新漏洞 S2
- IOS7系统最新漏洞
- ios最新漏洞?
- Tomcat最新漏洞说明
- Nginx最新解析漏洞
- java and snmp 第14章
- ORA-03113: end-of-file on communication channel
- Unpacking Storm Worm : Code and Import Address Table onto the heap
- GDB概述
- 所谓程序高手就是不断的顿悟不断的糨糊不断的持续努力坚持出来的
- 最新dns漏洞相关
- 一个带时钟的日历效果
- linux find命令-exec参数的使用说明 (转载)
- SNMP亲密接触
- 几个正则表达式
- CSDN开始推荐新年度微软MVP了,请大家尽快与我们联系!
- Struts-config.xml配置文件《action-mappings》元素的详解
- nfs交叉编译环境的建立
- 1