OpenBSD Journal

file(1) local hole

Contributed by jose on from the strange-but-true dept.

ycel na inlab na inlab kay bert writes :
" http://www.idefense.com/advisory/03.04.03.txt

openbsd's version of file is 3.22 and therefore vulnerable. but until now seems no errata entry on the openbsd site. i finished just cvs'ing 3.2-stable now, but seems no updates to file(1) at all."

It looks like no -stable updates to file will be provided, but if you run OpenBSD 3.2-stable (and probably 3.1-stable) you may want to roll your own patch for this. Basically, some products run file(1) to figure out how to process unknown data. If you routinely run file(1) on untrusted data, you may want to prepare your own patch. From the looks of things you can drop -current's source code for file(1) into a 3.2 system.

(Comments are closed)

Comments

  1. By tedu () on

    When you use cvs to update, remember to use -d after up to get new files you'll need to build.

    Comments

    1. By Anonymous Coward () on

      Can somebody give a more detailed description of how we would replace the 3.2 file with -current?

  2. By Anonymous Coward () on

    Theo, on misc@, didn't seem too concerned (http://marc.theaimsgroup.com/?l=openbsd-misc&m=104697017400696&w=2)

    Comments

    1. By Anonymous Coward () on

      Just hope he doesn't shoot himself in the foot with a comment like that.

      Comments

      1. By zil0g () on

        not likely.

        Comments

        1. By Anonymous Coward () on

          probably

    2. By converter () on

      Yes, as a matter of fact, we do run file(1) against random binaries often, that's what it's for. We process data and document conversions from off-site and file is an important tool for sorting out the messes we're expected to work with.

      Failure to release an official patch to address this issue for the reason Theo implied would be shortsighted and create unnecessary risk for users.

      Comments

      1. By Anonymous Coward () on

        I completely agree. 'file' is a probing tool, there is no need to run file on /bin/ls because I already know what is there. However I might use it on some random files a friend sends me, just to sort things out. Theo is a machine, but this one isn't gonna fly.

      2. By Anonymous Coward () on

        we do not run programs as root and we are safe as we cannot set effective suid program according to default mount permisions (nodev nosuid)

        moral - be farsighted and do not use uid(0) in everyday trade

        Comments

        1. By Anonymous Coward () on

          Just because a program is not suid root doesn't mean it cannot seriously compromise your machine. A non-suid exploit could for example do some key logging and wait for you to type su or sudo and would log and forward your password and then the cracker's got root access.

          The no-care attitude that is being shown by the OBSD development team in this matter is really outrageous.

          Comments

          1. By RC () on

            If you have an account that has serious permissions, then use systrace.


            ~/.profile
            alias file='systrace file'


      3. By Do Not Disturb Any Further () on

        Yup. If they've determined that patching this is not a priority because of a bunch of reasons, that's fine. If it is considered low-risk because of a handful of reasons, that's also fine.

        Deciding that it's low-risk and a non-problem because it's an executable that can be run against other arbitrary executables, but won't because "people just don't do that" is lame.

        It's an overflow. It can be exploited. Therefore, it will be.

    3. By Anonymous Coward () on

      I guess tcp/ip does not need arp.

  3. By anders () on

    If you follow the misc conversation for a bit, this exploit for the file(1) issue has already turned up.

    http://www.securityfocus.com/archive/1/314150

    Comments

    1. By Martin Johansson () martinj@maths.lth.se on mailto:martinj@maths.lth.se

      And if you try the exploit, you will find that it doesn't work on OpenBSD's version of file(1).

      A quick peek inside file.c reveals the follwoing:

      #ifdef BUILTIN_ELF
      if (match == 's' && nbytes > 5)
      tryelf(fd, buf, nbytes);
      #endif

      infact the entire readelf.c-file is surrounded by a #ifdef BUILTIN_ELF / #endif-pair.

      And since BUILTIN_ELF is not defined anywhere, it would seem that OpenBSD have been safe for quite some time. (the comment in readelf.c would suggest 1998/07/10)

      /Martin

  4. By Anonymous Coward () on

    Whatever happened to this...

    (from http://www.openbsd.org/security.html)

    "OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than Sun, SGI, IBM, HP, or other vendors are able to. We can make changes the vendors would not make."

    More uncompromising view?? Uhhh....

    Make changes the vendors would not make?? Uhhh... looks like this time the other vendors made changes first. I believe Red Hat has already released a patch.

    Come on, it's just a damn patch, do everyone a favor.

  5. By Anonymous Coward () on

    It looks like the patches finally made it into the patch branch.

    Compilation instructions are (probably):

    cd /usr/src/usr.bin/file
    make obj
    make
    make install

  6. By Anonymous Coward () on

    Just as a final note, in case you didn't catch it, according to this comment http://deadly.org/commentShow.php3?sid=20030310023846&pid=69 (which I have verified myself), the affected file, readelf.c, is by default not included in the compile. Thus OpenBSD is by default not vulnerable.

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