Slashdot Mirror

← Back to Stories (view on slashdot.org)

Vulnerability in make (1)

Posted by Nik on from the I-want-makeworld.com dept.

This security advisory and associated patch documents and fixes a security hole in Berkeley Make, relating to the "-j" option and temporary file name handling. The advisory was issued by the FreeBSD security team, but it is believed that NetBSD and OpenBSD are affected as well. Obviously, if you have downloaded Berkeley Make to a non-BSD system then you should investigate as well.

11 comments

  1. Re:OpenBSD not Effected by Anonymous Coward · · Score: 0

    But in another thread on the OpenBSD misc list, Theo pretty much pointed out that almost no one used the conditions to exploit the code under OpenBSD. But they fixed it anyways.

  2. Re:Not for OpenBSD by Anonymous Coward · · Score: 0

    >>This is exactly the sort of thing that a code audit for security can flush out and fix, so it should come as no surprise that OpenBSD fixed it.

    Matthew's point refer's to how beneficial a code audit is. A code audit of FreeBSD is exactly what prompted this SA. It wasn't clear to me if Matthew was suggesting FreeBSD needed a code audit or that he was aware of it and giving out props.

    Brian D. McGlothlin
    dskyzd@naxsDOTnet

  3. Not for OpenBSD by Matthew+Weigel · · Score: 0

    As howardjp pointed out, OpenBSD is not affected (I'm repeating it since I get a +1 Bonus and this will be seen by people, since moderators rarely come here -- if a moderator sees this, please moderate his post, rather than mine, up).

    This is exactly the sort of thing that a code audit for security can flush out and fix, so it should come as no surprise that OpenBSD fixed it.

    --
    --Matthew
    1. Re:Not for OpenBSD by kkenn · · Score: 1

      OpenBSD fixed _a_ problem some time ago, namely the use of mktemp instead of mkstemp, which is really a fairly perfectionist thing and not a major problem. However they (Theo and Todd) only thought they'd fixed the problem I reported to them - in their earlier change they didn't actually look at HOW the tempfile was being used - turns out the same randomly-generated filename was being repeatedly created and removed, thus making a trivial race to exploit with or without mkstemp().

      No real harm done - the make -j option has maximum performance on an SMP machine (which OpenBSD unfortunately do not support), although many people do report performance boosts even on uniprocessors since it makes better concurrent use of resources, e.g. CPU time for one job while the next is being read from disk.

      I should also state for the record that FreeBSD is in the process of being audited in much the same way as OpenBSD was - we've already turned up a number of bugs which they missed, so I hope the combined efforts of the problems fixed by the two teams (FreeBSD is merging over all of OpenBSD's fixes as well) should leave both OSes pretty darn secure!

  4. Re:OpenBSD not Effected by howardjp · · Score: 1

    DOH! Didn't see that one come across the list. :) That same message also says that a fix was just committed.

    Just out of curiosity, is there anyone someone can just update everything which could be classified as a "security fix" in FreeBSD or OpenBSD?

  5. Re:How to solve your problems by Arandir · · Score: 1

    All processes are equal, but some are more equal than others...

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  6. bad link in story to security advisory by Bogatyr · · Score: 1

    The actual file is at ftp:/ /ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeB SD-SA-00%3A01.make.asc.

  7. Re:Does not surprise me. by treat · · Score: 3
    The other problem it is possible on many UNIX systems to delete files that you don't own in the /tmp directory. There are some UNIXes that don't allow this, but it creates an exception to the normal UNIX file handling rules.

    Huh? /tmp is always mode 1777. 1000 is the sticky bit (+t in chmod's symbolic modes). In a +t directory, users can't rename/unlink/rmdir files or directories they don't own. This is supported in every modern Unix, and is no doubt mentioned in every standard who's scope covers Unix file permissions.

  8. OpenBSD not Effected by howardjp · · Score: 4

    Todd Miller posted to misc@openbsd.org yesterday saying that this bug was fixed "quite some time" ago in OpenBSD. A copy of his message can be seen here.

    1. Re:OpenBSD not Effected by nikc · · Score: 4
      Todd Miller posted to misc@openbsd.org yesterday saying that this bug was fixed "quite some time" ago in OpenBSD.

      And then he followe d up to his own message, explaining that OpenBSD was vulnerable...

      N

  9. Does not surprise me. by Bryan+Andersen · · Score: 4

    This dosen't surprise me one bit. Many programs use /tmp files rather badly. Most open them with world readability thus possibly disclosing contents. I'll admit even I have written scripts and programs that do poor file handling in the /tmp directory.

    The other problem it is possible on many UNIX systems to delete files that you don't own in the /tmp directory. There are some UNIXes that don't allow this, but it creates an exception to the normal UNIX file handling rules.

    Combining the poor file handling and being able to delete others files in /tmp one can do all sorts of exploits to gain root or access to others accounts.