Hi,
Michael Gilbert wrote:
> debianutil's tempfile (and coreutil's mktemp as well) expose security
> issues when an attacker has control of the TMPFILE environment variable.
> I believe that support for this variable should be disabled. Note that
> scripts that expect to set the tmpfile directory can use the "-d"
> option to obtain the same functionality.
>
> I suppose some users will want to retain control of this, but they'll
> just have to get used to finding temp files forced into /tmp.
I don't think that's worth it. TMPDIR is useful for causing programs to
store their temporary files on some partition with more space, and it even
can be used to enhance security by putting temporary files somewhere not
world-writable (e.g., ~/.tmp).
On the other hand, I am happy you are looking to extrapolate beyond a
single bug to think about related cases. Some comments about this one
below[1].
Cheers,
Jonathan
[1] The crux in bug #635849 is that if the user is allowed to
influence TMPDIR or the template argument then the filename returned
by tempfile and mktemp cannot be trusted not to contain shell
metacharacters; but properly quoting all variables is already good
policy in shell scripts anyway. A more general lesson might be that
unnecessarily using double-quoted strings like
trap "rm -rf \"\$scratch_dir\"" INT EXIT
in a shell script is dangerous and should be considered bad style,
because it is too easy to forget to escape something. Better to use
single quotes when appropriate:
trap 'rm -rf "$scratch_dir"' INT EXIT
It might be possible to teach a static analysis tool like lintian to
warn about interpolation in the argument to "trap" to catch this class
of bug (underescaping). Such a check would have some false positives,
but maybe not too many.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
