OpenBSD Journal

SECURITY FIX: All Architectures (revision 2)

Contributed by deanna on from the errata dept.

As posted on security-announce, a second revision of the patch fixing incorrect mbuf handling for ICMP6 packets has been created and is now available via the URLs given below.

Please make sure you get the second revision of the patch, as noted in the patch files.

OpenBSD 3.9 errata 020.

OpenBSD 4.0 errata 010.

If you have already applied the first revision of this patch to your kernel source, you will want to restore the original file before applying revision 2.

# cd /usr/src/sys/kern
# cp uipc_mbuf2.c.orig uipc_mbuf2.c

and then apply revision 2 of the patch.

(Comments are closed)

Comments

  1. By Cobalt (70.162.93.223) on

    I hope the lead time is big enough that this also makes it into 4.1

    Any explanation for why the second revision of the patch?

    Comments

    1. By Yves (87.194.39.146) on

      This is not looking good for OpenBSD to have released a defective patch.

      Comments

      1. By Noryungi (noryungi) on

        > This is not looking good for OpenBSD to have released a defective patch.

        The first patch was not "defective": it did not cover all the bases.

        Comments

        1. By Anonymous Coward (74.115.21.120) on

          > > This is not looking good for OpenBSD to have released a defective patch.
          >
          > The first patch was not "defective": it did not cover all the bases.

          Uh, what do you think defective means? A patch that is supposed to fix a security hole, but fails to completely fix it is defective. The first patch was defective, and this second one was just as poorly handled as the first.

          Comments

          1. By henning (213.39.157.103) on

            > > > This is not looking good for OpenBSD to have released a defective patch.
            > >
            > > The first patch was not "defective": it did not cover all the bases.
            >
            > Uh, what do you think defective means? A patch that is supposed to fix a security hole, but fails to completely fix it is defective. The first patch was defective, and this second one was just as poorly handled as the first.

            the patch was not defective at all and fixes the problem.
            the second revision includes a missing null pointer check.

      2. By Anonymous Coward (216.93.163.234) on

        > This is not looking good for OpenBSD to have released a defective patch.
        >

        Gobbles is still around?

        Comments

        1. By Anonymous Coward (74.119.84.96) on

          > Gobbles is still around?

          Gobbles we miss you!

    2. By Anonymous Coward (141.89.66.2) on

      > I hope the lead time is big enough that this also makes it into 4.1

      See http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/uipc_mbuf2.c
      and look for OPENBSD_4_1_BASE.

      The second revision of the patch did *not* make it into 4.1-release.

  2. By Anonymous Coward (75.58.18.77) on

    Wouldn't it make more sense to make it a separate patch and not a 2nd revision of it? It would probably lead to less confusion for users who already have patched it with 1st revision of this patch.

    Comments

    1. By Anonymous Coward (87.79.237.121) on

      It would, but then they'd have to bump the counter to 3, so
      nobody's going to do that ;)

      Comments

      1. By sthen (85.158.44.149) on

        > It would, but then they'd have to bump the counter to 3, so
        > nobody's going to do that ;)

        It's the same hole, it's just that the fix has been revised.

    2. By Anonymous Coward (122.49.157.192) on

      Agreed. This post indicates that the former patch was still correct, just not complete.
      http://marc.info/?l=openbsd-cvs&m=117412382109600&w=2

      -
      PS: hey... marc have updated some shit...

  3. By Anonymous Coward (193.95.206.48) on

    You should change:
    ------------------
    + if (n == NULL)
    + return (NULL);
    + M_DUP_PKTHDR(n, m);
    ------------------


    to:

    ------------------
    + if (n != NULL)
    + M_DUP_PKTHDR(n, m);
    ------------------

    or else version 1.23 is the same as version 1.23.2.2...


    Regards,
    TomazZ

    Comments

    1. By Anonymous Coward (193.95.206.48) on

      I was too quick... the patch is also ok...

      At this moment patch is not yet available from:
      ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.0.tar.gz

      Regards,
      TomazZ

      > You should change:
      > ------------------
      > + if (n == NULL)
      > + return (NULL);
      > + M_DUP_PKTHDR(n, m);
      > ------------------
      >
      >
      > to:
      >
      > ------------------
      > + if (n != NULL)
      > + M_DUP_PKTHDR(n, m);
      > ------------------
      >
      > or else version 1.23 is the same as version 1.23.2.2...
      >
      >
      > Regards,
      > TomazZ

  4. By Anonymous Coward (217.197.149.135) on

    Hello

    I follow stable branch. Few days ago I updated source tree from stable and compiled the kernel. But now when we have second revision of the patch. Do I need to delete or "downgrade" the affected file, or will it be merged from the source repository correctlly?

    Thanks

    Comments

    1. By Cabal (Cabal) on http://www.enginuity.org/

      > Hello
      >
      > I follow stable branch. Few days ago I updated source tree from stable and compiled the kernel. But now when we have second revision of the patch. Do I need to delete or "downgrade" the affected file, or will it be merged from the source repository correctlly?
      >
      > Thanks

      I would think it would have taken you less time to check your kernel source against this latest patch than to type out your post, no?

    2. By Marc Balmer (213.189.152.34) mbalmer@openbsd.org on

      > I follow stable branch. Few days ago I updated source tree from stable and compiled the kernel. But now when we have second revision of the patch. Do I need to delete or "downgrade" the affected file, or will it be merged from the source repository correctlly?

      If you checked out and compiled the -stable branch, then all you have to do is to update the sources using cvs update and recompile the kernel. The patch has been committed to the -stable branch. You only need to manually apply the patch if your are using a -release source tree.

    3. By Anonymous Coward (24.84.108.103) on

      > I follow stable branch. Few days ago I updated source tree from stable
      > and compiled the kernel. But now when we have second revision of the
      > patch. Do I need to delete or "downgrade" the affected file, or will it
      > be merged from the source repository correctlly?

      # cd /usr/src/sys/kern
      # rm *

      Then run cvsup again and you'll download the latest sources and won't have to worry about patching.

      Comments

      1. By Anonymous Coward (122.49.157.192) on

        > # cd /usr/src/sys/kern
        > # rm *
        >
        > Then run cvsup again and you'll download the latest sources and won't have to worry about patching.

        Oh come now, this is all silly. Even if you don't know how to cvs up, or patch, looking at the patches themselves would show that its trivial to manually apply the NULL check yourself in whatever branch you follow.

        Comments

        1. By Anonymous Coward (83.170.102.67) on

          > Oh come now, this is all silly. Even if you don't know how to cvs up, or > patch, looking at the patches themselves would show that its trivial to > manually apply the NULL check yourself in whatever branch you follow.

          That would require a majority of these complaining Neanderthals had any intelligence, Why can't people evolve already?

  5. By Anonymous Coward (63.19.141.254) on

    Hey, where is the patch to patch the patch ? geeesh ...I wonder what netbsd would say. Oh wait didn't you get the TCP report I faxed it to you. The first patch was invalidated by the second patch but the versioning number is still in order, we are not changing the cvs versioning to back date patches ( hehe ). By the way they killed Kenny and i'm not fat. Who has number 9 they're next ! Let's see thats one, two, three, three, three, number 9, number 9, number 9. Get the new patch version number scale it is emperical.
    Signed,
    Stan

  6. By Anonymous Coward (141.76.45.35) on

    They just PIMPED your patch

  7. By Justin (216.17.68.210) on

    Here is my fix and has been in place since day 1 of this box

    # grep inet6 /etc/pf.conf
    block in quick inet6

  8. By Anonymous Coward (141.89.66.2) on

    The file ftp.openbsd.org/pub/OpenBSD/patches/4.0/common/010_m_dup1.patch has been overwritten at least once (says a comment inside that file) and it is not under revision control. The file openbsd.org/errata40.html (which is under revision control) makes readers aware of this fact.

    The file ftp.openbsd.org/pub/OpenBSD/patches/4.0/common/008_icmp6.patch has been overwritten at least once (says a comment inside that file) and it is not under revision control. The file openbsd.org/errata40.html does not make readers aware of this fact.

    Conclusion:

    If you want to run OpenBSD X.Y-release plus errata, it is insufficient to look for new files names under ftp.openbsd.org/pub/OpenBSD/patches/X.Y/ and for changes to openbsd.org/errataXY.html

    You would have to periodically fetch ftp.openbsd.org/pub/OpenBSD/patches/X.Y.tar.gz and examine the diff -r between the two most recently downloaded and untarred instances of that file.

    Alternatively, you could track X.Y-stable which is under proper revision control.

  9. By Anish (216.6.64.135) anishax@gmail.com on

    Is this vulnerability exist in openbsd3.8?

    Comments

    1. By Anonymous Coward (205.240.34.148) on

      > Is this vulnerability exist in openbsd3.8?

      I would work under the assumption that it does and upgrade accordingly. OpenBSD only supports its previous release. So 3.8 has been unsupported since 4.0, and we are almost to 4.1.

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