Actual BIND error - Patching OpenBSD 4.3 named ?

[Andreas Maus-2]

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.

[Rod Whitworth-3]

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.

[mark reardon]

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 <glisten@...>:

> 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.

[Andreas Maus-2]

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
<glisten@...>.

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.

[Steve Tornio-2]

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

[Stuart Henderson]

On 2008-07-09, Steve Tornio <swtornio@...> 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.

[mikem-7]

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.

[mark reardon]

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 <stu@...>:

> On 2008-07-09, Steve Tornio <swtornio@...> 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.

[Stuart Henderson]

On 2008-07-09, Stuart Henderson <stu@...> 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.

[Ted Unangst-2]

On 7/9/08, Stuart Henderson <stu@...> 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.

[Steve Tornio-2]

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 55555 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 55555 shouldn't  
match the ebay query, and the poisoning shouldn't work.

If I'm missing something, I welcome any corrections.

Thanks,
Steve

[Ted Unangst-2]

On 7/9/08, Steve Tornio <swtornio@...> 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. :(

[openbsd misc]

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: owner-misc@... [mailto:owner-misc@...]
> 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 <swtornio@...> 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. :(

[Stuart Henderson]

On 2008-07-09, mark reardon <mcreardon@...> 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/)

[David Krause]

* Stuart Henderson <stu@...> [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