Joey Hess wrote:
> Noah Meyerhans wrote:
> > Upon investigating this for stable, I wonder if the problem is as bad as
> > reported. It seems that archivemail sets up its own temp directory and
> > creates its files in it:
> >
> > # create a temporary directory for us to work in securely
> > old_temp_dir = tempfile.tempdir
> > tempfile.tempdir = None
> > new_temp_dir = tempfile.mktemp('archivemail')
> > assert(new_temp_dir)
> > os.mkdir(new_temp_dir)
> > _stale.temp_dir = new_temp_dir
> > tempfile.tempdir = new_temp_dir
> > vprint("set tempfile directory to '%s'" % new_temp_dir)
> >
> > I don't really know python at all, but it seems like it might be OK. Do
> > you agree?
>
> Not being a python programmer, I missed the tempfile.tempdir setting,
> which, if it makes tempfile.mktemp use that temp dir, should make the
> program safe for all calls to mktemp from then on. Whether it's
> exploitable would thus depend on whether there are any calls to the
> other functions first. It seems like those calls all happen afterwards,
> I'm not 100% sure.
I've examined this, and I think there is no security issue in
archivemail.py.
There are four calls to tempfile.mktemp(): two in the constructor of
the ArchiveMbox class, one in the RetainMbox class constructor, and
finally, one in the archive() function. The latter is the code section
Noah has cited above, and since the umask is set to 077 before and
tempfile.tempdir is set, it should all be safe. Though I'd say it's
still reasonable to patch the code to use mkstemp() instead.
> The test suite still seems raceable for sure, though that's lower
> exploitability.
Agreed. Does this whole thing warrant a CVE?
Nikolaus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
