[dev] imp-2.2.4 tmpfile problems ?

[Brent J. Nordquist]

On Mon, 21 May 2001, Jarno Huuskonen <Jarno.Huuskonen@uku.fi> wrote:

> I tested this with both php-3.0.18 / php-4.0.5 with upload_tmp_dir set
> to /tmp (safe mode off)
           ^^^^^^^^^^^^^
What's the point?  The ownership checks in PHP 4.0.5 copy() aren't
effective unless you run in safe mode.

> IMHO upload_tmp_dir/safe_mode should be mentioned in imp/docs/SECURITY.

We can do that.

> Is the upcoming 2.2.5 going to have any security patches ?

That's why I'm asking the question right now, before I cut it.  We're only
interested in serious security issues with the 2.2.x branch.

> - 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)

Seems like this is essentially the same scenario as the copy() issue we're
discussing?

> - (and the php3 problem that: php-3.0.18 doesn't use mkstemp/O_EXCL in tempnam
>   (this is not imp problem,

Exactly.  :-)

> but might be worth mentioning in imp/docs/SECURITY))

That we can do.

> > 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.
>
> Ok, so when imp calls
> copy(safe_file($file_upload),safe_file($file_upload).'.att') the destination
> .att file has to exist ?

No, clearly not.

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

However, the safe_mode provision should cover this... assuming it works
properly.  (And if it doesn't, it's arguably a PHP problem.)  But for
2.2.x we're interested in knowing if the "predictable destination
filename" results in an exploitable vulnerability.

-- 
Brent J. Nordquist <bjn@horde.org> N0BJN
Yahoo!: Brent_Nordquist / AIM: BrentJNordquist / ICQ: 76158942