OpenBSD Journal

Security Fix: Possible heap overflow in file(1)

Contributed by merdely on from the file-heap dept.

Patches are available for OpenBSD 4.0 (#015, errata) and OpenBSD 4.1 (#009, errata) which address a possible heap overflow in file(1) (CVE-2007-1536).

From dim@'s commit message (backported by ckuethe@):

When writing data into a buffer in the file_printf() function, the length of the unused portion of the buffer is not correctly tracked, resulting in a buffer overflow when processing certain files.

Time to patch your systems!

(Comments are closed)


  1. By Brynet (Brynet) on

    All patched up here... although that was a slightly odd patch.. no biggy! :)

    1. By Mike Erdely (merdely) on http://erdelynet.com/

      > All patched up here... although that was a slightly odd patch.. no biggy! :)

      In that you have to apply it in /usr/src/usr.bin/file instead of /usr/src? I noticed that too.
      Broke my binpatch build. But was easy enough to get around. :)

      1. By Mike Swanson () on

        > In that you have to apply it in /usr/src/usr.bin/file instead of /usr/src? I noticed that too.
        > Broke my binpatch build. But was easy enough to get around. :)
        >

        I don't know, I just used CVS to update :)

    2. By Alvin () on

      When will OpenBSD provide binary patch file?

      1. By Karl Sjödahl (Dunceor) on

        > When will OpenBSD provide binary patch file?
        >

        Probobly never.

        There are inofficial binary patches though.

      2. By Anonymous Coward () on

        > When will OpenBSD provide binary patch file?

        Just the instant you pony up the cash for it.

      3. By Dean () on

        > When will OpenBSD provide binary patch file?
        >
        >

        Yes, it is called the next snapshot. Use at your own risk, but hey, snapshots become releases when it is time. Not exactly what you asked for, but it does get you protection without having to compile everything.

    3. By Chris Kuethe () ckuethe@ on

      > All patched up here... although that was a slightly odd patch.. no biggy! :)

      Sorry for generating the patch in the wrong place... my bad.

      1. By Brynet (Brynet) on

        > Sorry for generating the patch in the wrong place... my bad.

        All is well and good... I just noticed that the official patch on the errata page was modified to fix this issue though.

  2. By Peter N. M. Hansteen (pitrh) peter@bsdly.net on http://bsdly.blogspot.com/

    looking over the patch from ftp it struck me that the patch instructions generally say something like

    cd /usr/src

    patch <patchfile

    cd to/final/destination

    followed by the instruction to run several sequentially dependent makes, ie

    make obj
    make cleandir
    make depend
    make
    make install

    generally it makes sense to save time by stringing them together with &&, as in

    $ sudo make obj && sudo make cleandir && sudo make depend && sudo make && sudo make install

    so would it not make sense to put that form in the patch instructions instead?

    Except of course weeding out the ones who are unable to figure that bit out themselves.

    No biggie, possibly I just need more coffee.

    1. By Anonymous Coward () on

      I dare say the form in the instructions is used for clarity.

    2. By Mike Swanson () on

      There's also people that rebuild the entire system just for things like this. Oh well...

  3. By Anonymous Coward () on

    Would be nice to be able to download a file(1) file exploit, or even code to generate file exploits.
    Point is, I'd like to know what files do this and to what extent. Seen file(1) crash before, but ignored it. Is it worth it to test file(1) out, or just wait a few months/year for Blackhat conference, or some hackers to write it up?
    Any thoughts would be appreciated. I'm learning what I can, but tracking down some of this, seems for ME, a waste of time, need to learn programming and OpenBSD more.
    As a sideline, in OpenBSD 4.0 cdrom version, as a user, if you hit w <cr> as fast as you can, sometimes, you can make it abort, on a Dell Inspiron 4000, not seen on other hardware. Point, concern, are there lots of overflows a user can easily hit? Seen some other weird stuff, logged it, but if file(1) is not trustable and secure, then all this seems scary for the IT world. I can only imagine how bad Microsoft/etc really is. Life.
    Peace all.

    1. By Anonymous Coward () on

      -3 for 3, thats not bad.
      Guess my reporting on some little flaws and other thing not mentioned, goes unreported.
      But thats ok, what some want, some get.

  4. By Sebastian () on

    Hi all,

    From the looks of the patch this fault looks rather difficult to spot.

    Was this bug found by an incident, fuzzing, code review? It would be interesting to know how you find those bugs.

    Thanks for your answer!

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