Re: Actual BIND error - Patching OpenBSD 4.3 named ?
Anthony Roberts wrote: I don't think this actually accomplishes much. It still lets poisoned replies back in on the previous port number. hm... I don't think it does. BIND would, but it's going through PF. Without an additional rule to pass in to user named, the UDP reply has to be to the new NATed port. That's the only thing the state associated with the pass out on egress rule is going to be aware of. Eg, I applied the PF rule to one of my machines and checked, here's one of the states: all udp x.y.z.201:42001 - x.y.z.201:60538 - 68.142.196.63:53 MULTIPLE:MULTIPLE I don't care that someone can forge a packet from 68.142.196.63:53 to x.y.z.201:60538, the goal of the NAT rule in this case is to prevent the attacker from finding out what local port I'm using with anyone else. Without that NAT rule, everyone sees 42001. With that NAT rule, the attacker won't discover what local port I'm using for other DNS servers like google or yahoo or whatever. The lookup they get me to do against their domain doesn't have the same local port as the others. If the local port is known, there's apparently some other attacks that can build on that. You can use PF to randomize the source port on a standalone DNS server, but using the loopback as your query source and a NAT rule, you will need to enable IP forwarding for this to work.: /var/named/etc/named.conf: query-source address 127.0.0.1 port *; /etc/pf.conf: nat on $ext_if from 127.0.0.0/8 to any - $ext_if # pfctl -s s| grep 127.0.0 all udp 127.0.0.1:44954 - x.x.x.x:62246 - 207.46.66.126:53 MULTIPLE:MULTIPLE all udp 127.0.0.1:44954 - x.x.x.x:60491 - 65.55.238.126:53 MULTIPLE:MULTIPLE all udp 127.0.0.1:44954 - x.x.x.x:56006 - 198.170.241.130:53 MULTIPLE:MULTIPLE all udp 127.0.0.1:44954 - x.x.x.x:56851 - 198.170.241.131:53 MULTIPLE:MULTIPLE all udp 127.0.0.1:44954 - x.x.x.x:62635 - 192.43.172.30:53 MULTIPLE:SINGLE all udp 127.0.0.1:44954 - x.x.x.x:56918 - 216.211.140.226:53 MULTIPLE:SINGLE all udp 127.0.0.1:44954 - x.x.x.x:57970 - 209.128.76.101:53 MULTIPLE:MULTIPLE all udp 127.0.0.1:44954 - x.x.x.x:53076 - 209.128.76.102:53 MULTIPLE:MULTIPLE Dustin Lundquist
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
I don't think this actually accomplishes much. It still lets poisoned replies back in on the previous port number. hm... I don't think it does. BIND would, but it's going through PF. Without an additional rule to pass in to user named, the UDP reply has to be to the new NATed port. That's the only thing the state associated with the pass out on egress rule is going to be aware of. Eg, I applied the PF rule to one of my machines and checked, here's one of the states: all udp x.y.z.201:42001 - x.y.z.201:60538 - 68.142.196.63:53 MULTIPLE:MULTIPLE I don't care that someone can forge a packet from 68.142.196.63:53 to x.y.z.201:60538, the goal of the NAT rule in this case is to prevent the attacker from finding out what local port I'm using with anyone else. Without that NAT rule, everyone sees 42001. With that NAT rule, the attacker won't discover what local port I'm using for other DNS servers like google or yahoo or whatever. The lookup they get me to do against their domain doesn't have the same local port as the others. If the local port is known, there's apparently some other attacks that can build on that.
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
On 2008-07-09, mark reardon [EMAIL PROTECTED] wrote: doxpara.com reports no issues with unbound FWIW. right, unbound already randomises the source port (arc4random from guess where) and also the source address if you list more than one (assign aliases to the interfaces, and list all of the IP address in outgoing-interface lines in config). http://nlnetlabs.nl/publications/DNS_cache_poisoning_vulnerability.html they have their own methods to avoid stomping on ports used by other UDP services, but since they don't have control over the rest of the OS, it's a bunch of config parameters, not quite as elegant as using net.inet.udp.baddynamic populated from /etc/services entries (see recent commits in source- changes or in odc on www.squish.net/openbsd/)
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
* Stuart Henderson [EMAIL PROTECTED] [080709 07:15]: mcbride@ pointed out that you can give named some more protection by natting outbound udp traffic destined for port 53 (even just on the box running the resolver, it doesn't have to be on a firewall in front). something like, nat on egress proto udp from (self) to any port 53 - (self) there - if you need to tell people you're doing something while you wait for a better solution, you have an option. check this with tcpdump and requests from multiple NS, the doxpara.com checker will not notice this as an improvement. It doesn't notice this as an improvement because it is making multiple requests to the same name server, and pf will map all these requests using the same outgoing port. David
Actual BIND error - Patching OpenBSD 4.3 named ?
Hi. I guess OpenBSDs named is affected by the actual issue: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447 http://www.kb.cert.org/vuls/id/800113 So I hope a patch is in progress ? Or is OpenBSD not affected by this issue? So long, Andreas. -- Windows 95: A 32-bit patch for a 16-bit GUI shell running on top of an 8-bit operating system written for a 4-bit processor by a 2-bit company who cannot stand 1 bit of competition.
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
On Wed, 9 Jul 2008 11:10:09 +0200, Andreas Maus wrote: Hi. I guess OpenBSDs named is affected by the actual issue: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447 http://www.kb.cert.org/vuls/id/800113 So I hope a patch is in progress ? Or is OpenBSD not affected by this issue? So long, Andreas. -- # tcpdump -nettti rl0 dst port 53 tcpdump: listening on rl0, link-type EN10MB Jul 09 19:48:27.786683 00:01:80:0f:2b:94 00:00:24:c6:18:85 0800 70: 192.168.80.4.16284 192.168.80.1.53: 57120+ A? pps.com.au. (28) Jul 09 19:48:43.690332 00:01:80:0f:2b:94 00:00:24:c6:18:85 0800 67: 192.168.80.4.1356 192.168.80.1.53: 32536+ A? ibm.com. (25) Jul 09 19:49:11.013223 00:01:80:0f:2b:94 00:00:24:c6:18:85 0800 69: 192.168.80.4.14540 192.168.80.1.53: 29420+ A? intel.com. (27) # uname -a OpenBSD master.witworx.com 4.3 GENERIC#698 i386 Guess again. Was that so hard to try? R/ ** note replies off-list are not required. If you insist you MUST use the reply-to: address. The sender address is a tarpit except for the list servers. *** Rod/ A consultant is someone who's called in when someone has painted himself into a corner. He's expected to levitate his client out of that corner. -The Sayings of Chairman Morrow. 1984.
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
Hi Andreas, Aren't you dumping on the wrong interface here? Should it not be your $ext_if where the alleged poisoning will come from? 2008/7/9 Rod Whitworth [EMAIL PROTECTED]: On Wed, 9 Jul 2008 11:10:09 +0200, Andreas Maus wrote: Hi. I guess OpenBSDs named is affected by the actual issue: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447 http://www.kb.cert.org/vuls/id/800113 So I hope a patch is in progress ? Or is OpenBSD not affected by this issue? So long, Andreas. -- # tcpdump -nettti rl0 dst port 53 tcpdump: listening on rl0, link-type EN10MB Jul 09 19:48:27.786683 00:01:80:0f:2b:94 00:00:24:c6:18:85 0800 70: 192.168.80.4.16284 192.168.80.1.53: 57120+ A? pps.com.au. (28) Jul 09 19:48:43.690332 00:01:80:0f:2b:94 00:00:24:c6:18:85 0800 67: 192.168.80.4.1356 192.168.80.1.53: 32536+ A? ibm.com. (25) Jul 09 19:49:11.013223 00:01:80:0f:2b:94 00:00:24:c6:18:85 0800 69: 192.168.80.4.14540 192.168.80.1.53: 29420+ A? intel.com. (27) # uname -a OpenBSD master.witworx.com 4.3 GENERIC#698 i386 Guess again. Was that so hard to try? R/ ** note replies off-list are not required. If you insist you MUST use the reply-to: address. The sender address is a tarpit except for the list servers. *** Rod/ A consultant is someone who's called in when someone has painted himself into a corner. He's expected to levitate his client out of that corner. -The Sayings of Chairman Morrow. 1984.
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
On Wed, Jul 09, 2008 at 11:19:24AM +0100, mark reardon wrote: Hi Andreas, Aren't you dumping on the wrong interface here? Should it not be your $ext_if where the alleged poisoning will come from? Hi Mark. Excuse me? The tcpdump was provided by Rod Whitworth [EMAIL PROTECTED]. So long, Andreas. -- Windows 95: A 32-bit patch for a 16-bit GUI shell running on top of an 8-bit operating system written for a 4-bit processor by a 2-bit company who cannot stand 1 bit of competition.
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
On Jul 9, 2008, at 4:53 AM, Rod Whitworth wrote: # tcpdump -nettti rl0 dst port 53 tcpdump: listening on rl0, link-type EN10MB Jul 09 19:48:27.786683 00:01:80:0f:2b:94 00:00:24:c6:18:85 0800 70: 192.168.80.4.16284 192.168.80.1.53: 57120+ A? pps.com.au. (28) Jul 09 19:48:43.690332 00:01:80:0f:2b:94 00:00:24:c6:18:85 0800 67: 192.168.80.4.1356 192.168.80.1.53: 32536+ A? ibm.com. (25) Jul 09 19:49:11.013223 00:01:80:0f:2b:94 00:00:24:c6:18:85 0800 69: 192.168.80.4.14540 192.168.80.1.53: 29420+ A? intel.com. (27) # uname -a OpenBSD master.witworx.com 4.3 GENERIC#698 i386 Guess again. Was that so hard to try? I get a different result using the external interface of my caching name server, and mine looks vulnerable. frank# tcpdump -nettti em1 dst port 53 tcpdump: listening on em1, link-type EN10MB Jul 09 05:54:23.291421 00:0f:1f:04:8c:36 00:02:b9:38:23:f0 0800 82: xx.xx.9.35505 205.177.95.83.53: 27972 A? a1397.g.akamaitech.net. (40) Jul 09 05:54:25.814869 00:0f:1f:04:8c:36 00:02:b9:38:23:f0 0800 86: xx.xx.95.9.35505 75.126.144.219.53: 58999% [1au] A? www.virg9lio.it. (44) Jul 09 05:54:25.862953 00:0f:1f:04:8c:36 00:02:b9:38:23:f0 0800 87: xx.xx.95.9.35505 75.126.144.219.53: 2869% [1au] A? www.virgbilio.it. (45) Jul 09 05:54:35.864421 00:0f:1f:04:8c:36 00:02:b9:38:23:f0 0800 87: xx.xx.95.9.35505 75.126.217.184.53: 43066% [1au] A? www.virgbilio.it. (45) Jul 09 05:54:42.188507 00:0f:1f:04:8c:36 00:02:b9:38:23:f0 0800 102: xx.xx.95.9.35505 216.239.36.10.53: 20026% [1au] A? safebrowsing.clients.google.com. (60) Jul 09 05:54:42.214185 00:0f:1f:04:8c:36 00:02:b9:38:23:f0 0800 91: xx.xx.95.9.35505 64.233.167.9.53: 29212% [1au] A? clients.l.google.com. (49) Jul 09 05:54:42.347093 00:0f:1f:04:8c:36 00:02:b9:38:23:f0 0800 85: xx.xx.95.9.35505 198.105.192.254.53: 9616% [1au] A? log.wip.go.com. (43) Jul 09 05:54:42.678103 00:0f:1f:04:8c:36 00:02:b9:38:23:f0 0800 96: xx.xx.95.9.35505 64.233.167.9.53: 17632% [1au] A? static.cache.l.google.com. (54) frank# uname -a OpenBSD frank.placeholder.com 4.3 GENERIC#698 i386
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
On 2008-07-09, Steve Tornio [EMAIL PROTECTED] wrote: I get a different result using the external interface of my caching name server, and mine looks vulnerable. named is. the stub resolver isn't. mcbride@ pointed out that you can give named some more protection by natting outbound udp traffic destined for port 53 (even just on the box running the resolver, it doesn't have to be on a firewall in front). something like, nat on egress proto udp from (self) to any port 53 - (self) there - if you need to tell people you're doing something while you wait for a better solution, you have an option. check this with tcpdump and requests from multiple NS, the doxpara.com checker will not notice this as an improvement.
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
On 7/9/2008 at 5:58 AM Steve Tornio wrote: |On Jul 9, 2008, at 4:53 AM, Rod Whitworth wrote: | | | # tcpdump -nettti rl0 dst port 53 | tcpdump: listening on rl0, link-type EN10MB | Jul 09 19:48:27.786683 00:01:80:0f:2b:94 00:00:24:c6:18:85 0800 70: | 192.168.80.4.16284 192.168.80.1.53: 57120+ A? pps.com.au. (28) | Jul 09 19:48:43.690332 00:01:80:0f:2b:94 00:00:24:c6:18:85 0800 67: | 192.168.80.4.1356 192.168.80.1.53: 32536+ A? ibm.com. (25) | Jul 09 19:49:11.013223 00:01:80:0f:2b:94 00:00:24:c6:18:85 0800 69: | 192.168.80.4.14540 192.168.80.1.53: 29420+ A? intel.com. (27) | | | # uname -a | OpenBSD master.witworx.com 4.3 GENERIC#698 i386 | | Guess again. | | Was that so hard to try? | |I get a different result using the external interface of my caching |name server, and mine looks vulnerable. [snip] |frank# uname -a |OpenBSD frank.placeholder.com 4.3 GENERIC#698 i386 = fwiw, I used the test on the website (http://www.doxpara.com/) and my OpenBSD 4.3 named server was flagged as vulnerable.
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
doxpara.com reports no issues with unbound FWIW. Thanks to Stuart for this suggestion during the previous DJBware for ports thread. 2008/7/9 Stuart Henderson [EMAIL PROTECTED]: On 2008-07-09, Steve Tornio [EMAIL PROTECTED] wrote: I get a different result using the external interface of my caching name server, and mine looks vulnerable. named is. the stub resolver isn't. mcbride@ pointed out that you can give named some more protection by natting outbound udp traffic destined for port 53 (even just on the box running the resolver, it doesn't have to be on a firewall in front). something like, nat on egress proto udp from (self) to any port 53 - (self) there - if you need to tell people you're doing something while you wait for a better solution, you have an option. check this with tcpdump and requests from multiple NS, the doxpara.com checker will not notice this as an improvement.
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
On 2008-07-09, Stuart Henderson [EMAIL PROTECTED] wrote:
nat on egress proto udp from (self) to any port 53 - (self)
thanks to those who pointed out (self) includes 127.0.0.1, so you
don't want to use - (self), rather use - (egress).
e.g. nat on egress proto udp from (self) to any port 53 - (egress),
if you have a larger address space available you can use more
of it, e.g. you can use {192.0.192.0/24} random on a firewall in
front of name servers.
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
On 7/9/08, Stuart Henderson [EMAIL PROTECTED] wrote: mcbride@ pointed out that you can give named some more protection by natting outbound udp traffic destined for port 53 (even just on the box running the resolver, it doesn't have to be on a firewall in front). something like, nat on egress proto udp from (self) to any port 53 - (self) I don't think this actually accomplishes much. It still lets poisoned replies back in on the previous port number.
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
On Jul 9, 2008, at 12:19 PM, Ted Unangst wrote: n front). something like, nat on egress proto udp from (self) to any port 53 - (self) I don't think this actually accomplishes much. It still lets poisoned replies back in on the previous port number. But does it allow a poisoned reply from the spoofed address? As I understand the threat, based on the limited information: 1. Attacker sends valid user a www.badman.com link to click on 2. Resolver queries to badman.com NS from port 5 for www.badman.com, which is a CNAME to www.ebay.com 3. New query for www.ebay.com to ebay.com NS originates from udp port 54321 4. A spoofed UDP packet from the badman.com NS using 5 shouldn't match the ebay query, and the poisoning shouldn't work. If I'm missing something, I welcome any corrections. Thanks, Steve
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
On 7/9/08, Steve Tornio [EMAIL PROTECTED] wrote: I don't think this actually accomplishes much. It still lets poisoned replies back in on the previous port number. But does it allow a poisoned reply from the spoofed address? oh, right. I think I forgot even UDP packets have IP addresses. :(
Re: Actual BIND error - Patching OpenBSD 4.3 named ?
http://cr.yp.to/djbdns/run-cache.html http://www.ro.kde.org/djbdns/mywork/jumbo/index.html I never understood the mix of authoritive server and resolver ... Use dnscache as resolver and you you're (AFAIK) save. Regards Hagen Volpers -Urspr|ngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Ted Unangst Gesendet: Mittwoch, 9. Juli 2008 20:10 An: Steve Tornio Cc: misc Betreff: Re: Actual BIND error - Patching OpenBSD 4.3 named ? On 7/9/08, Steve Tornio [EMAIL PROTECTED] wrote: I don't think this actually accomplishes much. It still lets poisoned replies back in on the previous port number. But does it allow a poisoned reply from the spoofed address? oh, right. I think I forgot even UDP packets have IP addresses. :(
