Vulnerability in make(1)

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.

Re:OpenBSD not Effected

[howardjp]

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?

Re:How to solve your problems

[Arandir]

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

bad link in story to security advisory

[Bogatyr]

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

Re:Not for OpenBSD

[kkenn]

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!

Re:Does not surprise me.

[treat]

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.

OpenBSD not Effected

[howardjp]

Todd Miller posted to [e-mail] yesterday saying that this bug was fixed "quite some time" ago in OpenBSD. A copy of his message can be seen here. [sigmasoft.com]

Re:OpenBSD not Effected

[nikc]

Todd Miller posted to [e-mail] yesterday saying that this bug was fixed "quite some time" ago in OpenBSD.

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

N

Does not surprise me.

[Bryan Andersen]

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.