BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000
| CERT VU#800113 DNS Cache Poisoning Issue
Expect updates for every DNS server implementation (except for DJB), this could be interesting.
quote:
CERT VU#800113 DNS Cache Poisoning Issue
ISC characterization: Query Port Randomization for BIND 9
Added 2008.07.08
CVE: CVE-2008-1447
CERT: VU#800113
Versions affected: BIND 8 (all versions)
BIND 9 (all versions)
Severity: High
Known exploits to date: None
Summary:
A weakness in the DNS protocol may enable the poisoning of caching recurive resolvers with spoofed data. DNSSEC is the only full solution. New versions of BIND provide increased resilience to the attack.
»www.isc.org/index.pl?/sw/bind/bi···rity.php
--
Overpower, overcome. |
|
evilghost
Premium
join:2003-11-22
Springville, AL
 ·Windstream
| Debian released a security announcement at »www.debian.org/security/2008/dsa-1603 which states:
quote:
This update changes Debian's BIND 9 packages to implement the recommended countermeasure: UDP query source port randomization. This change increases the size of the space from which an attacker has to guess values in a backwards-compatible fashion and makes successful attacks significantly more difficult.
|
|
Cabal
Premium
join:2007-01-21
Boston, MA
1 edit | reply to BeesTea
Massive, Coordinated Patch To the DNS Released
Heh, 81 vendors.
--
Would you trust a brain surgeon with two years' experience? |
|
garywk
join:2001-03-06
Clarkston, WA
| reply to BeesTea
said by BeesTea  :Expect updates for every DNS server implementation (except for DJB), this could be interesting. quote:
CERT VU#800113 DNS Cache Poisoning Issue
ISC characterization: Query Port Randomization for BIND 9
Added 2008.07.08
CVE: CVE-2008-1447
CERT: VU#800113
Versions affected: BIND 8 (all versions)
BIND 9 (all versions)
Severity: High
Known exploits to date: None
Summary:
A weakness in the DNS protocol may enable the poisoning of caching recurive resolvers with spoofed data. DNSSEC is the only full solution. New versions of BIND provide increased resilience to the attack.
» www.isc.org/index.pl?/sw/bind/bi···rity.php Most vendors have most likely already released patches for this. As was already noted Debian did today, and I'd bet most other distros did the the same thing as this patch has been being worked on for quite a while. The way I understand it the patch and the vulnerability were released the same day as a planned move.
--
“We will bankrupt ourselves in the vain search for absolute security.”
Dwight David Eisenhower |
|
BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000
| said by garywk :The way I understand it the patch and the vulnerability were released the same day as a planned move. That's correct. All vendors were notified over the last few months and public fixes started appearing today. Folks who have access to private resources like ISC Forum likely had the fix a month ago.
--
Overpower, overcome. |
|
nevertheless
Premium,VIP
join:2002-03-08
Burlington, ON
 ·Cogeco Cable
2 edits | reply to BeesTea
said by BeesTea :Expect updates for every DNS server implementation (except for DJB) Buahahaha. |
|
GILXA1226
Premium,MVM
join:2000-12-29
London, OH
clubs:
| said by nevertheless :said by BeesTea :Expect updates for every DNS server implementation (except for DJB) Buahahaha. Anyone know if DJBdns is open to this risk at all? I'm too lazy to look. |
|
shdesigns
Powered By Infinite Improbabilty Drive
Premium
join:2000-12-01
Stone Mountain, GA
·Atlantic Nexus
| said by GILXA1226 :said by nevertheless :said by BeesTea :Expect updates for every DNS server implementation (except for DJB) Buahahaha. Anyone know if DJBdns is open to this risk at all? I'm too lazy to look. DJB DNS and qmail are perfect, just ask DJB 
--
Scott Henion
Embedded Systems Consultant, shenion on #ATU @irc.freenode.net
SHDesigns home |
|
Cabal
Premium
join:2007-01-21
Boston, MA
| reply to GILXA1226
said by GILXA1226 :said by nevertheless :said by BeesTea :Expect updates for every DNS server implementation (except for DJB) Buahahaha. Anyone know if DJBdns is open to this risk at all? I'm too lazy to look. It doesn't look like it.
"Also not affected: DJBDNS's IPv6 and IXFR functionality, since Dan didn't want to bother implementing them." 
--
Would you trust a brain surgeon with two years' experience? |
|
sporkme
drop the crantini and move it, sister
Premium,MVM
join:2000-07-01
Morristown, NJ
·Optimum Online
| reply to GILXA1226
said by GILXA1226 :Anyone know if DJBdns is open to this risk at all? I'm too lazy to look. The source port randomization bit? Nope.
I noticed in the big list of vendors that PowerDNS also already did things "right".  |
|
EUS
Kill cancer
Premium
join:2002-09-10
Montreal, QC
clubs:  | reply to BeesTea
I've gone with PowerDNS for three years now, and have not regretted it.
--
~ Project Hope ~ |
|
sporkme
drop the crantini and move it, sister
Premium,MVM
join:2000-07-01
Morristown, NJ
·Optimum Online
| said by EUS :I've gone with PowerDNS for three years now, and have not regretted it. Can you pro and con it against BIND in a nutshell? I just stumbled upon it today. |
|
Selenia
join:2006-09-22
Pittsfield, MA
·Verizon Online DSL
·RoadRunner Cable
| reply to BeesTea
Am I vulnerable running pdnsd only available to my local network? All my Windows boxes are up to date and all Linux boxes use the very latest bind9 for DNS resolution. The DNS servers for the lookups are set static and have been reliable for years. The data is then cached by pdnsd. Again, pdnsd will only allow my local network as a client. |
|
EUS
Kill cancer
Premium
join:2002-09-10
Montreal, QC
clubs:
1 edit | reply to sporkme
Ease of use is #1, as there are no special formats required, just sql setups.
I would state security, but I'm not an expert, so i'll just say that lately, this DNS is as safe as your sql setup is. |
|
Cabal
Premium
join:2007-01-21
Boston, MA
| reply to BeesTea
It's worth noting that no implementation is immune, due to the ailing/aging DNS protocol spec. From CERT:
quote:
Randomized source ports can be used to gain approximately 16 additional bits of randomness in the data that an attacker must guess. ... It is important to note that without changes to the DNS protocol, these mitigations cannot completely prevent cache poisoning. However, if properly implemented, they reduce the chances of success for an attacker by several orders of magnitude and make attacks impractical.
DNS cache poisoning isn't going away, it's just harder today than it was yesterday (for many implementations). We'll see who comes along tomorrow and how clever they are...
--
Interested in open source engine management for your Subaru? |
|
deblin
Dark Side of the Moon
Premium,MVM
join:2001-09-01
Middletown, DE
| reply to BeesTea
I know there is a checker on http://www.doxpara.com/, but has anyone found a stand-alone tester that I can run from an external Unix shell?
If not, I suppose I could come up with a little script to test this. I'll have to read through the CERT more thoroughly to see how to implement a test.
--
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))' |
|
sporkme
drop the crantini and move it, sister
Premium,MVM
join:2000-07-01
Morristown, NJ
·Optimum Online
| said by deblin :I know there is a checker on http://www.doxpara.com/, but has anyone found a stand-alone tester that I can run from an external Unix shell? Hmmm... That's fun. It just told me a patched server is sending all queries from port 53. Time to poke around the config. |
|
nwrickert
sand groper
Premium,MVM
join:2004-09-04
Geneva, IL
 ·AT&T U-Verse
·AT&T Midwest
| It just told me a patched server is sending all queries from port 53. This is going to be a problem, though not necessarily for you.
Many organizations have strict firewalls, and set their DNS server to make queries with source port 53 as there way of allowing it to get through the firewall.
--
AT&T dsl; Westell 327w modem/router; SuSE 10.1; firefox 2.0.0.14 |
|
BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000
| reply to sporkme
said by sporkme :Hmmm... That's fun. It just told me a patched server is sending all queries from port 53. Time to poke around the config. You'll want to make sure your query-source variable in options doesn't include a port.
--
Overpower, overcome. |
|
garywk
join:2001-03-06
Clarkston, WA
| reply to nwrickert
said by nwrickert :It just told me a patched server is sending all queries from port 53. This is going to be a problem, though not necessarily for you. Many organizations have strict firewalls, and set their DNS server to make queries with source port 53 as there way of allowing it to get through the firewall. If that is a Debian box make sure that /etc/bind/named.conf.options is not specifying port 53. You can also check /var/log/daemon.log to see if bind9 is tied to one port or not. If it is you'll see a line like this:
/etc/bind/named.conf.options:10: using specific query-source port suppresses port randomization and can be insecure. |
|
