OpenBSD Journal

Security Fix: Bind cache poisoning vulnerability

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)

Comments

  1. By Anonymous Coward (217.197.149.135) on

    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

    Comments

    1. By jason (jason) on http://www.dixongroup.net/

      > 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

      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

      1. By Martin Gignac (192.75.88.232) on

        I just applied to the patch to an OpenBSD 4.3-RELEASE box and I'm seeing the same behavior as you.

        Comments

        1. By Anonymous Coward (2001:4830:123a:beef:21e:8cff:fe6f:7ae3) on

          Jul 23 15:59:25 x named[23931]: [child]: disallowed port 9068
          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

          1. By Anonymous Coward (2001:4830:123a:beef:21e:8cff:fe6f:7ae3) on

            Looks like check_bind() in privsep.c used to make sure that the port was always one of the three allowed ones:

            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.

      2. By Martin Gignac (216.144.126.125) on

        > 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

        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

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


      Comments

      1. By jason (jason) on http://www.dixongroup.net/

        > > 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 && port < 1024) || child_pid)
        Tested and works fine on 4.3-stable.

        Comments

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

          1. By jason (jason) on http://www.dixongroup.net/

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

            What I demonstrated would only have sent daemon.err messages for named to /dev/null. All of other logs would have continued.

    3. By Anthony (68.145.124.201) on

      Uhg.

      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.

    4. By Damien Miller (djm) on http://www.mindrot.org/~djm/

      > 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

      This warning is harmless, but a patch is on the way to silence it.

      Comments

      1. By Anonymous Coward (217.197.149.135) on

        > > 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
        >
        > This warning is harmless, but a patch is on the way to silence it.


        Thanks, it works with the new patch.

  2. By Anonymous Coward (75.166.167.238) on

    Does the snapshot I installed today:

    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

    1. By tedu (207.99.73.226) on

      > Does the snapshot I installed today:

      The snaps have had the fix for a while.

    2. By Anonymous Coward (69.196.152.39) on

      > Does the snapshot I installed today:
      >
      > 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?

    3. By Anonymous Coward (2a01:348:108:155:216:41ff:fe53:6a45) on

      > Does the snapshot I installed today:
      >
      > 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).

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

    cc  -I/usr/src/usr.sbin/bind/obj -I. -Iinclude -I/usr/src/usr.sbin/bind/obj/lib/dns/include
 -I/usr/src/usr.sbin/bind/lib/dns/include  -I/usr/src/usr.sbin/bind/obj/lib/isc/include
 -I/usr/src/usr.sbin/bind/lib/isc  -I/usr/src/usr.sbin/bind/lib/isc/include
 -I/usr/src/usr.sbin/bind/lib/isc/unix/include  -I/usr/src/usr.sbin/bind/lib/isc/nothreads/include
 -DUSE_MD5 -DOPENSSL  -O2 -pipe   -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat
 -Wpointer-arith -fno-strict-aliasing  -c /usr/src/usr.sbin/bind/lib/dns/acl.c
In file included from /usr/src/usr.sbin/bind/lib/dns/include/dns/types.h:154,
                 from /usr/src/usr.sbin/bind/lib/dns/include/dns/name.h:82,
                 from /usr/src/usr.sbin/bind/lib/dns/include/dns/acl.h:40,
                 from /usr/src/usr.sbin/bind/lib/dns/acl.c:26:
include/dns/enumtype.h:77: error: redefinition of `dns_rdatatype_dlv'
include/dns/enumtype.h:76: error: `dns_rdatatype_dlv' previously defined here
*** Error code 1

Stop in /usr/src/usr.sbin/bind/obj/lib/dns.
*** Error code 1

Stop in /usr/src/usr.sbin/bind/obj/lib (line 99 of Makefile).
*** Error code 1

Stop in /usr/src/usr.sbin/bind/obj (line 97 of Makefile).
*** Error code 1

Stop in /usr/src/usr.sbin/bind (line 54 of /usr/src/usr.sbin/bind/Makefile.bsd-wrapper).

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

     ***************
 ***************
 ***************   THIS FILE IS AUTOMATICALLY GENERATED BY gen.c.
 ***************   DO NOT EDIT!
 ***************
 ***************/
.
.
.
        dns_rdatatype_dlv = 32769,
        dns_rdatatype_dlv = 65323,
.
.
.

    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

  4. By Anonymous Coward (195.13.31.240) on

    http://www.trusteer.com/dnsopenbsd
    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

    1. By tedu (207.99.73.226) on

      > http://www.trusteer.com/dnsopenbsd
      > 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.

  5. By tedu (207.99.73.226) on

    reply to comment links are missing.

    Comments

    1. By jason (jason) on http://www.dixongroup.net/

      > reply to comment links are missing.

      No, they're just way off to the right because some jackass didn't wrap his comment properly.

      ---------------------------------------------------------------------->

    2. By tedu (207.99.73.226) on

      > reply to comment links are missing.

      oh, no, they're only 5 pages over. that's dumb. a stupid comment shouldn't break the page.

      Comments

      1. By Anonymous Coward (193.192.245.3) on

        Is

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

  6. By Luke Call (216.49.181.128) on

    Forgive me if this isn't the right place for this...I'm still learning.

    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

    1. By Damien Miller (djm) on http://www.mindrot.org/~djm/

      > Forgive me if this isn't the right place for this...I'm still learning.
      >
      > 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.

  7. By Luke Call (216.49.181.128) on

    Damien,
    (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.)

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]