Comcast_DNS
@aol.com
| reply to Sandy Wilbourn
Re: [DNS] Comcast and the DNS Server flaw issue
OK. my previous test display was 24 hours old, so I just repeated it, and the DNS warning is no longer there. However, the port range also seems to have been increased, which indicates to me that perhaps there were changes in the Comcast DNS infrastructure as well as possible changes in Dam Kaminsky's test. If so, then Comcast deserves praise for being so responsive, but instead we get typical Comcast denials, I guess some parts of the Comcast corporate culture are hard to shed. 
Your name server, at 68.87.68.164, appears to be safe, but make sure the ports listed below aren't following an obvious pattern.
------------------------------------------
Requests seen for d1df9c73c1f1.toorrr.com:
68.87.68.164:17824 TXID=2180
68.87.68.164:16908 TXID=31062
68.87.68.164:17486 TXID=58678
68.87.68.164:17804 TXID=43870
68.87.68.164:17734 TXID=59408
|
|
jlivingood
Premium,VIP
join:2007-10-28
Philadelphia, PA
| said by Comcast_DNS :OK. my previous test display was 24 hours old, so I just repeated it, and the DNS warning is no longer there. However, the port range also seems to have been increased, which indicates to me that perhaps there were changes in the Comcast DNS infrastructure as well as possible changes in Dam Kaminsky's test. If so, then Comcast deserves praise for being so responsive, but instead we get typical Comcast denials, I guess some parts of the Comcast corporate culture are hard to shed. Your name server, at 68.87.68.164, appears to be safe, but make sure the ports listed below aren't following an obvious pattern.
------------------------------------------
Requests seen for d1df9c73c1f1.toorrr.com:
68.87.68.164:17824 TXID=2180
68.87.68.164:16908 TXID=31062
68.87.68.164:17486 TXID=58678
68.87.68.164:17804 TXID=43870
68.87.68.164:17734 TXID=59408
That may also reflect an evolution of the tests themselves.
JL |
|
Comcast_DNS
@aol.com
thumbs down from:
Cabal 
| said by jlivingood :That may also reflect an evolution of the tests themselves. Wow, the Comcast culture is simply amazing.
First Dan Kaminsky faked the port range used by the Comcast DNS (and only the Comcast DNS), but after pressure from Comcast, he stopped doing it. Of course this is what happened, how could anyone think otherwise. |
|
Sandy Wilbourn
@nominum.com
| I'm not sure that I understand this post.
I have worked closely with Comcast on this whole thing since May (I am not a Comcast employee). They have been one of the most concered ISPs since that time. Comcast was very proactive and patched their DNS servers before the CERT advisory. That's a hugely positive thing and took moving a lot of parts around to get it done.
Then web-based tests to approximate the exploit were developed and released by multiple security analysts. BUT, if web-based tests do not accurately reflect a vulnerability that they expressly test for, do you not think they should be updated for accuracy? What you see is not those analysts being pressured by anyone. If you doubt that, you should contact Dan and others and ask them. Our interest should be in people having tests that accurately reflect whether or not a DNS is patched.
Sandy |
|
rolfp
join:2001-09-12
Oakland, CA
 ·Comcast
 ·EarthLink
| just copy/pastin' my way through life
afaict, this issue is being discussed, also, at ATU, with another diagnostic test for the vulnerability:
»CERT VU#800113 DNS Cache Poisoning Issue
This is not my bailiwick but that test seems not to give positive results for me.
dns-oarc has a web-test, also: »https://www.dns-oarc.net/
[..] |
|
jbob
Reach Out and Touch Someone
Premium
join:2004-04-26
Little Rock, AR
·Comcast
·AT&T Southwest
2 edits | Here's the results of the same test. Dang results all over the place:
»550534c6b13985d060430715.et.dns-oarc.net/
Oh and this is with Comcasts's DNS nameservers
Same test using OpenDNS nameservers.
»9656593288a74b47aa1c9010.et.dns-oarc.net/
Much better
So what are us lowly non network engineer types supposed to make of this. Is this a flawed test of Comcast or is the DoxPara test more accurate? |
|
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
 ·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| reply to rolfp
If you have sufficient transaction ID randomness, then to a certain degree the source port randomness is just an academic bonus.
The issue with Bind was that both the source port and the transaction ID for the requests were predictable, which made the poisoning not just possible, but actually quite likely if you scripted things correctly. |
|
rolfp
join:2001-09-12
Oakland, CA | OK, however, the folks at the thread in ATU I link are reporting 'GOOD' results when they apply the patch or update their dns server software. Wouldn't such a 'GOOD' result be expected from a patched Comcast server? |
|
deblin
Dark Side of the Moon
Premium,MVM
join:2001-09-01
Middletown, DE
| reply to rolfp
Verizon still has not addressed the issue for the source port randomness on their DNS servers either:
»7079aa1c5d30a1b7ccc245e6.et.dns-oarc.net/
I'm considering removing the forwarders I use for my caching nameserver, until Verizon gets their act together.
--
perl -le 'print $i=pack(c5,(8**2+3**2),42-10,sqrt(3600),oct(63),(unpack(c, "&")-6)),pack(c7, (70,114,101,101,66,83,68))' |
|
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| reply to rolfp
said by rolfp :OK, however, the folks at the thread in ATU I link are reporting 'GOOD' results when they apply the patch or update their dns server software. Wouldn't such a 'GOOD' result be expected from a patched Comcast server It would depend on what DNS server it is. These tools are for testing Bind, so they are assuming Bind post-patch behavior. The 3 key problems with Bind specifically are:
1) Transaction IDs were predictable
2) Source ports were predictable
3) There was no limit to the number of response "attempts" that would be processed for a query before a valid response is received.
For this exploit to work, you need to get a spoofed response packet shot into the DNS server before the real server's packet made it in. With bind you could predict what the next source port and transaction ID would be, so once you saw one query you could predict what the next would be. |
|
CableUZR
Cuidado, Hay Llamas
join:2003-02-04
Mount Holly, NJ
clubs:
| reply to jbob
To me it looks as though the test performed by OARC is using too small a sample size to give accurate standard of deviation numbers (the results seem precise, just not accurate). Standard deviation seems to be the only difference between results on the servers tested, and the difference is quite slight. As mentioned, the fact that some randomness has been added to the mix is a good thing, and makes exploiting the flaw much less likely. Could it be better? -Sure. Is it better than not patching at all -you bet. What would be a sufficient sample size to judge the randomness of the DNS resolver? -Ask a statistician... 
--
[/home/USA]$rm -rf /bin/bible_beaters |
|
Alan Clegg
@rr.com
 from:
Cabal
| reply to espaeth
Transaction ID is just not enough (even if 100% "random")
If you have sufficient transaction ID randomness, then to a certain degree the source port randomness is just an academic bonus.
The issue with Bind was that both the source port and the transaction ID for the requests were predictable, which made the poisoning not just possible, but actually quite likely if you scripted things correctly.
You sir, are completely incorrect.
Alan Clegg
aclegg@isc.org |
|
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| said by Alan Clegg :
If you have sufficient transaction ID randomness, then to a certain degree the source port randomness is just an academic bonus.
You sir, are completely incorrect. Completely ?
I will acknowledge that I overstated on source port randomness just being a bonus. Still, the most exploitable servers are those that are still using fixed source port queries, followed by the previous bind implementations that still had limited entropy for both the source port and transaction ID.
The servers being reported with "poor" source port randomness (ie, randomness within a fixed range) but "good" for transaction ID randomness are still better off than those servers out there still susceptible to »securitytracker.com/alerts/2007/···442.html . |
|
