OpenBSD Journal

OpenBSD & BIND 9 cache poisoning

Contributed by merdely on from the its-good-to-be-secure dept.

Jakob Schlyter (jakob@) wrote to misc@: 

as some of you may have noticed, a new weakness in BIND 9 has
recently been discovered.  using this weakness, an attacker can
remotely poison the cache of any BIND 9 server.  the attacker can do
this due to a weakness in the transaction ID generation algorithm used.

when BIND 9 was first imported into OpenBSD, we decided not to use
the default ID generation algorithm (LFSR, Linear Feedback Shift
Register) but to use a more proven algorithm (LCG, Linear
Congruential Generator) instead.  thanks to this wise decision, the
BIND 9 shipped with OpenBSD does not have this weakness.

the proactive security of OpenBSD strikes again,

        jakob

ref: http://www.trusteer.com/docs/bind9dns.html

(Comments are closed)

Comments

  1. By Darrin Chandler (dwc) dwchandler@stilyagin.com on http://www.stilyagin.com/darrin/

    This is just one of how many similar exploits that have not affected OpenBSD, due to proactive security? Many, many times! This is the difference between really caring about security vs. lip service.

  2. By Anonymous Coward (63.231.76.1) on

    Three cheers for OpenBSD! Hip Hip!

    Comments

    1. By wob (12.109.229.8) wob@bonch.org on

      > Three cheers for OpenBSD! Hip Hip!

      humppa!

      Hooray was just not going to cut it here. :)



  3. By Anonymous Coward (90.199.221.21) on

    Is the LCG significantly cheaper than asking the kernel for "proper" randomness in the same way that high ports are allocated? If not, what would be the reason for not using the kernel's entropy pool? Portability?

    Whatever the answer, well done OpenBSD for doing things right at the outset.

    Comments

    1. By mcbride (210.138.35.53) on

      > Is the LCG significantly cheaper than asking the kernel for "proper" randomness in the same way that high ports are allocated? If not, what would be the reason for not using the kernel's entropy pool? Portability?

      Because the DNS Query ID has other properties we need to maintain. In particular, we need it to be unique over a minimum time period, because it is used to disambiguated different DNS replies. If we used numbers from the kernel's entropy pool (or more likely, arc4random) there a significant chance that multiple dns requests could be send in close sequence with the same DNS ID, and the responses could get mixed up.

      The same principle applies to the IP ID used to reassemble fragmented IP packets (and in fact the same LCG algorithm is used there)

      http://www.openbsd.org/papers/asiabsdcon07-network_randomness/index.html

      Comments

      1. By Anonymous Coward (90.199.221.21) on

        Thank you for the explanation :)

  4. By Anonymous Coward (24.226.127.231) on

    Even tho I've come to expect this sort of thing from OpenBSD, I still find it hard to not be impressed. As always, fantastic work =)

  5. By Anonymous Coward (80.139.26.66) on

    Just for clarification: You found out about the problem, fixed it, but kept the knowledge for yourself? Or why has't any other distribution (or even upstream) integrated your fix?

    If you kept it for yourself thats probably "good service" for yourself but asshole service for the rest of the world and nothing to be proud of.

    Comments

    1. By Anonymous Coward (212.221.53.50) on

      > Just for clarification: You found out about the problem, fixed it, but kept the knowledge for yourself? Or why has't any other distribution (or even upstream) integrated your fix?
      >
      > If you kept it for yourself thats probably "good service" for yourself but asshole service for the rest of the world and nothing to be proud of.
      >

      You know how to bitch, but do you know how to read? I think not. If you had bothered reading the post, you wouldn't have to ask this question. The post clearly states that OpenBSD uses the other algorithm because of its proven track record. Get it?

    2. By Anonymous Coward (82.75.29.106) on

      > Just for clarification: You found out about the problem, fixed it, but kept the knowledge for yourself? Or why has't any other distribution (or even upstream) integrated your fix?
      >
      > If you kept it for yourself thats probably "good service" for yourself but asshole service for the rest of the world and nothing to be proud of.
      >

      I would not be surprised if the random-number generator exists in a library which exists in OpenBSD it self. Maybe it even makes use of some kernel features. It's probably not available on every platform, maybe it should be.

      The OpenBSD-developers could use it and they did because they are proactive.

      An other reason maybe that the bind-developers did not accept the patch from the OpenBSD-developers.

    3. By joe (76.103.54.83) on

      > Just for clarification: You found out about the problem, fixed it, but kept the knowledge for yourself? Or why has't any other distribution (or even upstream) integrated your fix?
      >
      > If you kept it for yourself thats probably "good service" for yourself but asshole service for the rest of the world and nothing to be proud of.
      >

      Nothing OpenBSD does is kept to themselves. It's all in CVS. If other projects don't care about learning from OpenBSD "correctness" and don't peruse the source tree, then it's their bad.

      OpenBSD didn't "found out about the problem" and "fixed it". OpenBSD audited the source code when they imported BIND. Whatever OS you're griping about doesn't audit their code with high standards, otherwise they would have found this bug and fixed it PROACTIVELY.

      OpenBSD practices PROACTIVE security. It says that on the webpage. No one's hiding anything.

      Go away troll...

      Comments

      1. By Julian (87.174.70.9) on

        > > Just for clarification: You found out about the problem, fixed it, but kept the knowledge for yourself? Or why has't any other distribution (or even upstream) integrated your fix?
        > >
        > > If you kept it for yourself thats probably "good service" for yourself but asshole service for the rest of the world and nothing to be proud of.
        > >
        >
        > Nothing OpenBSD does is kept to themselves. It's all in CVS. If other projects don't care about learning from OpenBSD "correctness" and don't peruse the source tree, then it's their bad.
        >
        > OpenBSD didn't "found out about the problem" and "fixed it". OpenBSD audited the source code when they imported BIND. Whatever OS you're griping about doesn't audit their code with high standards, otherwise they would have found this bug and fixed it PROACTIVELY.
        >
        > OpenBSD practices PROACTIVE security. It says that on the webpage. No one's hiding anything.

        They found something and didn't tell others. This is egocentric. I'm really gutted...

        > Go away troll...

        I'd prefer your leaving...

        Comments

        1. By Anonymous Coward (84.135.121.245) on


          > They found something and didn't tell others. This is egocentric. I'm really gutted...

          Do you even know what you're talking about? No you don't. It was _not_ found by OpenBSD. OpenBSD has absolutely _nothing_ to do with this bug.

        2. By Theo de Raadt (199.185.137.1) deraadt@openbsd.org on

          > They found something and didn't tell others. This is egocentric. I'm really gutted...

          Actually, we found the original problem with SNI (Secure Networks) and CORE (of Argentina) in 1997, and we fixed it at the same time in our version of the code, which was BIND 4 at the time. This is the problem reported and fixed in http://www.openbsd.org/advisories/res_random.txt

          Following that discovery and repair, the ISC people developing BIND 8 and BIND 9 went and developed their own LFSR-based solution to solve the same problem. Instead of using our cryptographically better solution, they went with their own solution because it put less pressure on the (non-existant) random number subsystems that current operating systems had. (They chose to use what systems had for RNG subsystems, rather than joining other projects at pressuring operating systems of the time to get onto the strong RNG bandwagon sooner).

          At the time we told them that we felt their solution was not as secure. We explained in detail why we thought our solution was better. They did not listen. We had gone through great efforts with the CORE guys (who did the math side of our non-repeating random number generator) to make sure that attacks of that kind would not be feasable. Remember that before these changes were basically id++.

          Before our posting, there was no solution to the id++ problem. After our solution, ISC went and independently developed an inferior solution rather than our solution. When we switched to BIND 9, we chose to stick with our own solution rather than use the inferior ISC developed mechanism. Glad we did so.

          Whoever you are, I wish you would cut your uneducated rhetoric and stop wasting everyone's time with slander. You know nothing about anything except spreading hate.

    4. By Anonymous Coward (70.173.172.228) on

      > Just for clarification: You found out about the problem, fixed it, but kept the knowledge for yourself? Or why has't any other distribution (or even upstream) integrated your fix?
      >
      > If you kept it for yourself thats probably "good service" for yourself but asshole service for the rest of the world and nothing to be proud of.
      >

      you're just mad you can't post "so will openbsd change the slogan on their front page now?" or something similar.

  6. By Robin Carey (86.27.166.246) on

    Wouldn't a superior solution be to use a CSPRNG (Crypto Secure Pseudo Random Number Generator) rather than a LCG generator ?

    Crypto secure generators are specifically designed so that new outputs cannot be predicted even with knowledge of previous output.

    Three good CSPRNGs that I know of are:

    ISAAC by Bob Jenkins,
    IBAA by Bob Jenkins,
    and
    L15 by myself, Robin Carey (L15 == fixed ARC4).

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