temp file creation problem in inn
rra at stanford.edu
Tue Jan 16 14:49:17 UTC 2001
Steve Beattie <steve at wirex.net> writes:
> A little more clarification on the issue -- RedHat's RPM passes
> configure the following arguments:
> Unfortunately, --with-tmp-dir is not a valid configure option (how nice
> of configure to silently ignore it, but that's an autoconf issue); the
> correct option is --with-tmp-path, and it should NOT be set to /tmp. So
> the security problem is the result of a misconfiguration by RedHat.
> However, I believe it is dangerous for INN to depend that its temp
> directory be non-world writable AND have configure set the default to
> %prefix/tmp if --with-tmp-path is not given. It is common for vendors to
> set --prefix to /usr and easy to miss that this is an unsafe
> configuration. If nothing else, a warning in the INSTALL file about the
> interdependence of --prefix and the temp directory is desired.
Just so that folks know, in case you didn't see the INN 2.3.1 release
announcement, INN now prints out the following message if it detects at
configure time that /tmp is writeable:
WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
The temporary directory you have configured is world-writeable. It is
currently set to $tmpdir.
This directory is used by INN for temporary files and should only be
writeable by the news user. INN does not go to great lengths to prevent
symlink attacks and the like because it assumes this directory is not
world-writeable. By configuring INN in this fashion, you may be
introducing a locally exploitable security hole.
It is STRONGLY recommended that you use a temporary directory reserved for
INN's exclusive use, one which is not world-writeable. You can do this
either with --with-tmp-dir or by setting --prefix to something other than
/usr or /.
There is also additional documentation in INSTALL about this under
--prefix and --with-tmp-path (which is now --with-tmp-dir in 2.4.0-to-be).
I'm currently playing with the idea of mailing BUGTRAQ about this, as I
see that one Linux vendor has already released a new INN package, but I'd
ideally like to give other vendors that shipped INN this way some advance
warning. Unfortunately, I have no idea the best way of contacting them or
even who might be affected.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-bugs