OpenBSD Journal

Security fix: Buffer overflow in zlib

Contributed by grey on from the we'll keep posting errata as stories dept.

Thanks to Richard, Tim McCormick, Rob and others for writing in to let us know about the zlib errata. And thanks to our readers who voted in our poll; with that input we will keep posting errata as stories, though be sure to the sidebar which is updated automatically. With that lead in, here is the following from security-announce@:

Insufficient checking in the zlib compression library (installed as libz on OpenBSD) can result in a buffer overflow and a program crash. It is not known at this time whether maliciously-crafted compressed files can be used to execute arbitrary code.

Since zlib is in wide use throughout the base OS, as well as in ports, users are advised to patch their systems as soon as possible.

A fix has been committed to OpenBSD-current as well as the 3.6 and 3.7 -stable branches. Patches are also available for OpenBSD 3.6 and 3.7. OpenBSD versions 3.4 and lower are not affected as they use an older version of zlib that does not contain the vulnerable code.

3.6 patch:
ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.6/common/019_libz.patch
3.7 patch:
ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.7/common/004_libz.patch

The 3.6 patch also applies to OpenBSD 3.5.

As always, be sure to check http://www.openbsd.org/errata.html as well.

(Comments are closed)


Comments
  1. By daddy2times (134.174.91.40) on

    Ha! I timed it perfectly this time! This patch is almost a week old (July 6th), now and I'm glad!

    I run a number of OpenBSD servers (patch branch) but I have an old and slow 'build' machine that I always use to build and create an iso to update all of the servers. Seems like every time I update to patch branch, make a release and make an iso (usually takes about 15 hours), there is new patch the next day or two.

    Luckily, I did all this over the weekend. For a moment there I thought I'd wasted all those cpu cycles again.

    (Of course, this doesn't preclude a new patch to be issued tomorrow, but I'll just keep my digits crossed :)

  2. By Chas (147.154.235.51) on

    The 3.6 patch also applies to OpenBSD 3.5.

    3.5 was/is a fantastic release. I bought the 3.7 CD set, but I am going to sit tight on 3.5 for several servers and try to hold out, maybe for 3.8 or even further.

    I do eye the improvements of later releases (privsep dhcp and ftp, smp, spamd tarpits, etc.), but so far nothing has made me want to jump ship.

    Thanks again for a 3.5-compatible patch!

    Comments
    1. By Anonymous Coward (69.158.152.118) on

      but so far nothing has made me want to jump ship

      How about security updates? I wouldn't expect 3.5 compatible patches all the time and you said you are running servers. Probably a good idea to run a release on servers that is supported by developers.

    2. By Ray Percival (12.18.141.172) on

      <honest_curiosity> As a recent convert from the Linux world I could understand this is you were running RH or even these days Debian or one of the less than really stable Linux distros. But OpenBSD has *never* had a rep of breaking things with new versions. In fact quite the opposite. So why would you stick with a old release? </honest_curiosity>

      Comments
      1. By Chas (147.154.235.51) on

        Upgrades in OpenBSD are sometimes more traumatic than you might realize...

        OpenBSD 3.4 introduced the ELF executable format, which broke binary compatibility (and made for a more difficult upgrade). Binary compatibility has been broken a few other times, but I started in at 3.2 so I'm not sure when. A wipe/reinstall was strongly advocated at 3.4.

        In a normal upgrade, many uninstall all packages, which can get very messy. A wipe/reinstall is advocated when convenient.

        Upgrades are only supported between adjacent version numbers, unlike redhat where skipping both minor and major releases works.

        i386 went to gcc3 in 3.7. gcc3 has its own problems - the one that bit me was the inability to compile C code that calls varargs.h (fwtk won't build completely anymore - http-gw compile dies).

        It is common to see a number of other "gotchas" in the upgrade documentation from release to release.

        Comments
        1. By Anonymous Coward (220.240.54.229) on

          I hope you not expecting FWTK http-gw to compile when 3.8 is released? You may need to actually fix http-gw for your problems to go away. Maybe you should be looking at solutions way better than the unsupported, not been worked on in years'n'years FWTK.

        2. By Marc Espie (62.212.102.210) espie@openbsd.org on

          Converting code using varargs.h to modern C style is more or less trivial. Don't expect varargs.h to ever work again.

          I haven't seen any request from you anywhere to actually port that software to OpenBSD, and fix the varargs stuff...

          Comments
          1. By Marc Espie (62.212.102.210) espie@openbsd.org on

            Oh right, I forgot.

            FWTK isn't free software, and it's not maintained any more, hasn't
            been for 7 years, in fact.

            What's the point ? There's bound to be holes in that software. I won't know for sure, because I'm not going to go through an obnoxious licence agreement to look at the code.

            But 7 years old, come on, seriously... you're trusting your gw security on 7 years old stuff ?

            Comments
            1. By Chas (147.154.235.52) on

              I'm currently using fwtk to isolate a QA network of VAX, Unisys, and HP-UX systems. This is not being done for security, but for development and testing purposes, and it is a lot simpler to do with fwtk than pf. I don't care about security in this case, as long as these QA servers don't touch anything on my real network. My current round of kudos for getting this done obviate any condemnation that you might proffer.

              If I am relying upon the fwtk code at all, then OpenBSD would be the place to do it, since I have W^X and ProPolice on this platform.

        3. By Ray Percival (12.18.141.172) ray.percival@summitsite.com on

          "unlike redhat where skipping both minor and major releases works."

          Been awhile since you last worked with RH, hasn't it. :P

      2. By m0rf (68.104.17.51) on

        because he wants to run 3.5 supported forever. He wants the developers to waste time supporting a specific release for life, and he says he'll pay for it. I guess he just likes uptimes > 1 year.

        If he has the money to pay for a supported 3.5 system for life, he probably has enough money to hire a bunch of coders to support it for him without begging on undeadly.org for it.



        Comments
        1. By djm@ (218.214.226.34) on

          I don't see anything in his post that suggests that he expects developers to do extra work for him. Some people want/need to run older systems, and that is perfectly OK so long as they know what they are getting themselves in for (and he/she seems to). So, lay off the reflexive fanboy criticism.

          Comments
          1. By m0rf (68.104.17.51) on

            not in that post, just in others by him, so lay off the reflexive defence.

            Comments
            1. By djm@ (203.217.30.86) on

              Evidence?

              Comments
              1. By Chas (147.154.235.53) on

                ...I have said a few times that I would like 5-year support for a "stable" OpenBSD release. I've learned to be quiet about it, and appreciate everything that I can get.

      3. By Anonymous Coward (82.73.147.65) on

        People don't know what it takes to do a proper upgrade and don't want to know. They want the claimed automatic upgradebility to work. And that's what noone can offer. The reason, /etc nust be updated with something that resembles mergemaster. As a matter of fact a proper Linux upgrade is easier than a OpenBSD upgrade, since every file is packaged and old systemfiles and libraries are removed. The only thing RedHat doesn't offer is a method to upgrade /etc and that's why things break. A lot other distros do offer a tool for updating /etc OpenBSD has the update of /etc well documented (and also has mergemaster) and most people read the docs and can safely upgrade. Some people don't like reading but don't mind complaining. I wrote a set of scripts which automates the whole upgrade process, including the updating of /etc and the removal of old systemfiles. http://www.xs4all.nl/~hanb/software/OpenBSD-binary-upgrade/ Hmmm now I realize I should write a little script to update ports as well.

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