#878138 muttprint: still vulnerable to symlink attack (race condition)

#878138#5
Date:
2017-10-10 11:17:54 UTC
From:
To:
The muttprint Perl script contains:

        my $logf = "/tmp/muttprint.log";

        if (-e $logf)
        { ## 2008-12-24 -- Lukas Ruf
                # close CVE-2008-5368 -- muttprint vulnerable to symlink attack
                # ensure "/tmp/muttprint.log" adheres to the following constraints
                #       - owner is current user
                #       - only real files are allowed
                # if any of these fail, create a temporary file by use of tempfile()
[...]

So, it first tests whether /tmp/muttprint.log exists, and potentially
use an alternate pathname if it does. But if a /tmp/muttprint.log
symlink is created between the test (which returns false) and the
time this file is created, there's a security issue.

It would be sufficient to use a secure temporary file unconditionally
(and this is probably better, as more predictable).

BTW, using a hardcoded /tmp for temporary files is a bad idea anyway.

#878138#15
Date:
2017-10-10 12:16:28 UTC
From:
To:
which is there just because of this kind of bugs.

Note also that this is still an optional feature, and not all users
use Debian provided kernels.

#878138#20
Date:
2017-10-10 12:27:24 UTC
From:
To:
It is not optional, see the release notes section I quoted. If you run a custom kernel
you need to enable it, otherwise you're on your own.

Cheers,
        Moritz

#878138#27
Date:
2017-10-10 13:42:40 UTC
From:
To:
                                                      ^^^^^^^^^^
Thus, that's optional. There is no guarantee that it is enabled
after a system configuration change (done on purpose, due to a
bug, or whatever). One should not blindly rely on this feature.

#878138#32
Date:
2017-10-10 14:02:31 UTC
From:
To:
It is not optional. You omitted to quote the second part:

"/tmp-related bugs which are rendered non-exploitable by this mechanism
are not treated as security vulnerabilities. If you use a custom
Linux kernel you should enable it using a sysctl setting"

Cheers,
        Moritz

#878138#37
Date:
2017-10-10 14:34:58 UTC
From:
To:
The procfs(5) man page disagrees.

In any case, even though a symlink attack is not possible under this
condition, there's still a potential DoS in the code.