Contributed by jason on from the gentlemen-start-your-patching-engines dept.
Brad Smith (brad@) has committed the security fix, on behalf of Damien Miller (djm@), for the much-publicized DNS vulnerability (CVE-2008-1447). Patches are available for OpenBSD 4.2 and 4.3 -stable.
Update (Thu Jul 24 2008, 08:18:00 CEST): Brad has committed an update to this fix by Damien that will silence the (harmless) warnings that some users have discovered after applying the original security patch.
Continue reading for the commit messages...
OpenBSD 4.3:
CVSROOT: /cvs Module name: src Changes by: brad@cvs.openbsd.org 2008/07/23 11:39:39 Modified files: usr.sbin/bind/bin/named: Tag: OPENBSD_4_3 client.c server.c usr.sbin/bind/doc/arm: Tag: OPENBSD_4_3 Bv9ARM-book.xml Bv9ARM.ch06.html usr.sbin/bind/lib/dns: Tag: OPENBSD_4_3 api dispatch.c resolver.c usr.sbin/bind/lib/dns/include/dns: Tag: OPENBSD_4_3 dispatch.h usr.sbin/bind/lib/isc: Tag: OPENBSD_4_3 random.c shuffle.c usr.sbin/bind/lib/isc/unix: Tag: OPENBSD_4_3 app.c socket.c socket_p.h Log message: Vendor patch to add port randomization to deal with the DNS cache poisoning attack. Dynamically allocate fd_sets so we are not limited to FD_SETSIZE connections. From djm@
OpenBSD 4.2:
CVSROOT: /cvs Module name: src Changes by: brad@cvs.openbsd.org 2008/07/23 11:59:56 Modified files: usr.sbin/bind : Tag: OPENBSD_4_2 README.OpenBSD usr.sbin/bind/bin/named: Tag: OPENBSD_4_2 server.c usr.sbin/bind/lib/dns: Tag: OPENBSD_4_2 dispatch.c resolver.c usr.sbin/bind/lib/dns/include/dns: Tag: OPENBSD_4_2 dispatch.h usr.sbin/bind/lib/isc: Tag: OPENBSD_4_2 Makefile.in random.c usr.sbin/bind/lib/isc/include/isc: Tag: OPENBSD_4_2 random.h usr.sbin/bind/lib/isc/unix: Tag: OPENBSD_4_2 app.c socket.c socket_p.h Added files: usr.sbin/bind/lib/isc: Tag: OPENBSD_4_2 shuffle.c usr.sbin/bind/lib/isc/include/isc: Tag: OPENBSD_4_2 shuffle.h Log message: Vendor patch to add port randomization to deal with the DNS cache poisoning attack. Dynamically allocate fd_sets so we are not limited to FD_SETSIZE connections. Replacement Knuth shuffle algorithm for DNS id generation. From djm@
(Comments are closed)
By Anonymous Coward (217.197.149.135) on
Jul 23 21:23:24 titan named[30601]: [child]: disallowed port 25967
Jul 23 21:23:24 titan named[30601]: [child]: disallowed port 60918
....
I was not able to find anything on Google. For now I had to disable named logging in syslog.conf because Bind was filling my logs very fast.
Do you know what does it mean and how can I solve it? Thanks
Comments
By jason (jason) on http://www.dixongroup.net/
>
> Jul 23 21:23:24 titan named[30601]: [child]: disallowed port 25967
> Jul 23 21:23:24 titan named[30601]: [child]: disallowed port 60918
> ....
>
> I was not able to find anything on Google. For now I had to disable named logging in syslog.conf because Bind was filling my logs very fast.
>
> Do you know what does it mean and how can I solve it? Thanks
I'm also seeing this. A single recursive request generates four entries in /var/log/daemon.
Jul 23 17:43:11 foobar-2 named[23982]: [child]: disallowed port 21045
Jul 23 17:43:11 foobar-2 named[23982]: [child]: disallowed port 21042
Jul 23 17:43:11 foobar-2 named[23982]: [child]: disallowed port 56633
Jul 23 17:43:11 foobar-2 named[23982]: [child]: disallowed port 42890
Comments
By Martin Gignac (192.75.88.232) on
Comments
By Anonymous Coward (2001:4830:123a:beef:21e:8cff:fe6f:7ae3) on
Jul 23 15:59:25 x named[23931]: [child]: disallowed port 40991
Jul 23 15:59:25 x named[23931]: [child]: disallowed port 34802
# pfctl -ss | grep 34802
all udp xxx.xxx.x.33:34802 -> 73.14.247.241:53 MULTIPLE:SINGLE
# pfctl -ss | grep 40991
all udp xxx.xxx.x.33:40991 -> 73.14.247.242:53 MULTIPLE:SINGLE
# pfctl -ss | grep 9068
all udp xxx.xxx.x.33:9068 -> 73.14.247.242:53 MULTIPLE:SINGLE
Comments
By Anonymous Coward (2001:4830:123a:beef:21e:8cff:fe6f:7ae3) on
if (port != NAMED_PORT_DEFAULT && port != RNDC_PORT_DEFAULT &&
port != LWRES_PORT_DEFAULT) {
if (port || child_pid)
logmsg(LOG_ERR, "%s: disallowed port %u", pname, port);
return (1);
}
Since now we want to randomize these source ports, we can safely get rid of this check.
By Martin Gignac (216.144.126.125) on
>
> Jul 23 17:43:11 foobar-2 named[23982]: [child]: disallowed port 21045
> Jul 23 17:43:11 foobar-2 named[23982]: [child]: disallowed port 21042
> Jul 23 17:43:11 foobar-2 named[23982]: [child]: disallowed port 56633
> Jul 23 17:43:11 foobar-2 named[23982]: [child]: disallowed port 42890
Jason,
Maybe it's unrelated, but could these four entries be due to having just restarted BIND, and then issued a query for a domain name with four "components", such as:
hostname.subdivision.company.com
and then having BIND lookup the servers taking care of .com, .company.com, .subdivision.company.com, and then finally looking up the original complete query?
-Martin
By Gleydson Soares (gsoares) on http://www.trusted.com.br
>
> Jul 23 21:23:24 titan named[30601]: [child]: disallowed port 25967
> Jul 23 21:23:24 titan named[30601]: [child]: disallowed port 60918
> ....
>
> I was not able to find anything on Google. For now I had to disable named logging in syslog.conf because Bind was filling my logs very fast.
>
> Do you know what does it mean and how can I solve it? Thanks
>
hi,
i applied the patch and got the same problem here,
just apply the diff at http://www.trusted.com.br/bind.diff.txt
it'll help your syslog,
Comments
By jason (jason) on http://www.dixongroup.net/
That's entirely wrong. First, you can avoid the logging by just
adding this to the top of your syslog.conf.
Second, the actual problem is the line above the one you reference.
Tested and works fine on 4.3-stable.The actual fix (should be announced soon) is:
Comments
By Gleydson Soares (gsoares) on http://www.trusted.com.br
> After application of the patch I started to get strange messages
> comming from my named.
>
> Jul 23 21:23:24 titan named[30601]: [child]: disallowed port 25967
> Jul 23 21:23:24 titan named[30601]: [child]: disallowed port 60918
> ....
>
> I was not able to find anything on Google. For now I had to disable
> named logging in syslog.conf because Bind was filling my logs very
> fast.
>
> Do you know what does it mean and how can I solve it? Thanks
>
>
> hi,
> i applied the patch and got the same problem here,
>
> just apply the diff at http://www.trusted.com.br/bind.diff.txt
> it'll help your syslog,
>
>
> That's entirely wrong. First, you can avoid the logging by just
> adding this to the top of your syslog.conf.
>
>
> !!named
> daemon.err /dev/null
> !*
>
>
> Second, the actual problem is the line above the one you reference.
>
> The actual fix (should be announced soon) is:
>
>
> - if (port || child_pid)
> + if ((port
>
>
> Tested and works fine on 4.3-stable.
>
perhaps, that's wrong for a permanent solution.
i didn't wanted avoid the "named" logs. i needed BIND/logs enable through syslog to register others kind BIND/logs entries.
i think that bind/WARNINGS are harmless, then i sent to LOG_DEBUG.
the diff was a temporary solution while damien provide the definitive patch.
Comments
By jason (jason) on http://www.dixongroup.net/
>
> i think that bind/WARNINGS are harmless, then i sent to LOG_DEBUG.
>
> the diff was a temporary solution while damien provide the definitive patch.
What I demonstrated would only have sent daemon.err messages for named to /dev/null. All of other logs would have continued.
By Anthony (68.145.124.201) on
There's a PF-based workaround to this issue. I'm not inclined to roll out this patch immediately if it's going to fill up /var with useless debug messages.
By Damien Miller (djm) on http://www.mindrot.org/~djm/
>
> Jul 23 21:23:24 titan named[30601]: [child]: disallowed port 25967
> Jul 23 21:23:24 titan named[30601]: [child]: disallowed port 60918
> ....
>
> I was not able to find anything on Google. For now I had to disable named logging in syslog.conf because Bind was filling my logs very fast.
>
> Do you know what does it mean and how can I solve it? Thanks
This warning is harmless, but a patch is on the way to silence it.
Comments
By Anonymous Coward (217.197.149.135) on
> >
> > Jul 23 21:23:24 titan named[30601]: [child]: disallowed port 25967
> > Jul 23 21:23:24 titan named[30601]: [child]: disallowed port 60918
> > ....
> >
> > I was not able to find anything on Google. For now I had to disable named logging in syslog.conf because Bind was filling my logs very fast.
> >
> > Do you know what does it mean and how can I solve it? Thanks
>
> This warning is harmless, but a patch is on the way to silence it.
Thanks, it works with the new patch.
By Anonymous Coward (75.166.167.238) on
kern.version=OpenBSD 4.4-beta (GENERIC) #985 Tue Jul 22 18:14:49 MDT 2008
for i386 contain the fix?
I ran the isc.sans.org test:
dig @IP-of-GOOD +short porttest.dns-oarc.net TXT
and it reported back:
"IP-of-Good" is GOOD: 26 queries in 1.0 seconds from 26 ports with std dev 13882.18
But is that from the previous modifications the developers made to BIND a few months ago?
I also tried the python script from http://www.monkey.org/~provos/dnspredict.py but it just says "No model available"
I modified the script's first line to be #!/usr/local/bin/python2.5 so it is executing.
Thanks to the developers! Your work is greatly appreciated!
Comments
By tedu (207.99.73.226) on
The snaps have had the fix for a while.
By Anonymous Coward (69.196.152.39) on
>
> kern.version=OpenBSD 4.4-beta (GENERIC) #985 Tue Jul 22 18:14:49 MDT 2008
>
> for i386 contain the fix?
>
> I ran the isc.sans.org test:
>
> dig @IP-of-GOOD +short porttest.dns-oarc.net TXT
>
> and it reported back:
> "IP-of-Good" is GOOD: 26 queries in 1.0 seconds from 26 ports with std dev 13882.18
>
I assume that when running this against a local forwarding/caching NS, the IP that returned retuen the recursive query is in the output?
That is:
clvrmnky@fubar:/var/named $ dig @xx.yy.0.1 +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"aa.bb.cc.4 is GOOD: 26 queries in 2.3 seconds from 26 ports with std dev 19884.58"
Where "aa.bb.cc.4" is different than what I passed in, but is not either of my forwarding IPs (but is part of their netblock -- so I assume some sort of load-balancing artefact).
Anyone know if my guesses make sense?
By Anonymous Coward (2a01:348:108:155:216:41ff:fe53:6a45) on
>
> kern.version=OpenBSD 4.4-beta (GENERIC) #985 Tue Jul 22 18:14:49 MDT 2008
>
> for i386 contain the fix?
Yes. The fix in -current makes use of a few other infrastructure things that are a bit too involved for -stable (which just has ISC's fix) which make it work better. See the commits in the days following the initial announcement of the CVE if you missed them and want to know more.
-stable is there for people who have to have it, but if you are running busy recursive resolvers on OpenBSD, you really should just move them to -current (4.4 BETA).
By Anonymous Coward (211.27.16.195) on
I have a problem applying the patch (4.2)
I run OpenBSD 4.2 release, and keep it up to date applying patches per the errata page. http://openbsd.org/errata42.html - 013: SECURITY FIX: July 23, 2008 2nd revision.
I found it would not build. So I reversed the patch, to check if the original version would compile. I even download the source again to check if a clean version would compile.
In all cases I get the same error:
Indeed in /usr/obj/usr.sbin/bind/lib/dns/include/dns/enumtype.h, which is generated by the compile process (gen.c), that data definition is there twice...
At that point I am stuck.
I don't know how to work out how the build process generates that file (although make -f Makefile.bsd-wrapper clean gets rid of it).
I don't know which value is correct, even if I do work out how that file gets generated.
As I am not the only person attempting to apply this patch, and I can't find any other reports of it on Google, it's unlikely to be a general problem associated with the 'release' or 'stable' version, and is probably something specific to my systems' build options, which is causing this error.
But what?
Thanks in advance if you can assist.
Cheers, Sam
By Anonymous Coward (195.13.31.240) on
What do you think about this paper ? I know it's NOT the same bug as now but...
They discover a flaw in OpenBSD TXID and nothing was done by the OpenBSD team ?
Comments
By tedu (207.99.73.226) on
> What do you think about this paper ? I know it's NOT the same bug as now but...
> They discover a flaw in OpenBSD TXID and nothing was done by the OpenBSD team ?
>
This was fixed about 4 months ago.
By tedu (207.99.73.226) on
Comments
By jason (jason) on http://www.dixongroup.net/
No, they're just way off to the right because some jackass didn't wrap his comment properly.
---------------------------------------------------------------------->
By tedu (207.99.73.226) on
oh, no, they're only 5 pages over. that's dumb. a stupid comment shouldn't break the page.
Comments
By Anonymous Coward (193.192.245.3) on
<table width="100%">
<tr><td>
<pre>
Long long loooooooong line...
</pre>
</td></tr>
</table>
supposed to cause scrolling?
If so, how do you prevent it, short of breaking long lines unconditionally on submission?
By Luke Call (216.49.181.128) on
When applying revision #2 of the 004_bind.patch and when getting to the 2nd make step:
make -f Makefile.bsd-wrapper
...I get these compile errors:
[many lines starting with "cc..." or "making all in ..."]
cc -I/usr/src/usr.sbin/bind/obj -I/usr/src/usr.sbin/bind/lib/isc/unix/include
-I/usr/src/usr.sbin/bind/lib/isc/nothreads/include -I./include
-I/usr/src/usr.sbin/bind/lib/isc/include -O2 -pipe -W -Wall
-Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat
-Wpointer-arith -fno-strict-aliasing -c
/usr/src/usr.sbin/bind/lib/isc/hash.c
In file included from /usr/src/usr.sbin/bind/lib/isc/hash.c:68:
/usr/src/usr.sbin/bind/lib/isc/include/isc/refcount.h:23:24: isc/atomic.h: No such file or directory
***Error code 1
[etc...]
.
Here are some details: In order to apply this patch today I upgraded my 4.1 box to 4.2 then 4.3, and applied patches # 1 and #2 from the 4.3 errata to the source I just downloaded, followed the patch instructions through to make install (I did both at once with only one make install since they applied to the same source tree; I wasn't in a hurry previously, because I don't use ssh enough or X at all for the non-DNS fixes to matter much. I didn't apply errata #3 because I don't have xenocara on the system.) This is an older i386 system.
No results from google. I tried applying/compiling more than once and it does compile partway, successfully; earlier I had errors applying the patches but I blew away the /usr/src/usr.sbin/bind directory, re-untarred just that part from the source archive, and applying the patch subsequently worked, but compiling does not.
Ideas? Many thanks.
Comments
By Damien Miller (djm) on http://www.mindrot.org/~djm/
>
> When applying revision #2 of the 004_bind.patch and when getting to the 2nd make step:
> make -f Makefile.bsd-wrapper
> ...I get these compile errors:
did you do a "make -f Makefile.bsd-wrapper clean" first?
The instructions will be updated to include this step.
By Luke Call (216.49.181.128) on
(I'm not seeing how to reply directly to a message from the expanded undeadly view... hopefully the subject will tie these together well
enough.)
The 'clean' step was it. Thanks again. (Ahhh and with the keyboard being recognized again, separately, it's a good ending to that part of the day.)