Red Hat Bugzilla – Bug 1063658
CVE-2014-1932 python-pillow, python-imaging: insecure temporary file creation
Last modified: 2015-01-21 08:22:49 EST
Jakub Wilk discovered that temporary files were insecurely created (via mktemp()) in the IptcImagePlugin.py, Image.py, JpegImagePlugin.py, and EpsImagePlugin.py files of Python Imaging Library. A local attacker could use this flaw to perform a symbolic link attack to modify an arbitrary file accessible to the user running an application that uses the Python Imaging Library.
Further details are available in the original report:
Created python26-imaging tracking bugs for this issue:
Affects: epel-5 [bug 1063662]
Related: CVE-2014-1933 / bug 1063660
python-pillow is also affected:
Created python-pillow tracking bugs for this issue:
Affects: fedora-all [bug 1089795]
(In reply to Murray McAllister from comment #3)
> python-pillow is also affected:
Note that the above Pillow fix had a bug in the Image._dump() implementation. When _dump() was called with no filename and with format specified and different form PPM, temporary file used was not the one created by tempfile.mkstemp(), but rather a file with a name matching temporary file name followed by dot and format (i.e. with appended extension as .jpg or .png added). This could make it easier for a local attacker to exploit this case than the original code using tempfile.mktemp(), as it allows attacker to observe the actual temporary file name.
The regression was fixed in:
The Pillow itself only calls _dump() with specified format from ImageShow.py and only on Windows or Mac OS platforms.
Should I reference this bug when creating updates for python-pillow-2.2.1-6.fc20, python-pillow-2.0.0-15.gitd1c6db8.fc19 (which fix the issue pointed out in comment #5)? Or #1089795?
(In reply to Sandro Mani from comment #6)
> Should I reference this bug when creating updates for
> python-pillow-2.2.1-6.fc20, python-pillow-2.0.0-15.gitd1c6db8.fc19 (which
> fix the issue pointed out in comment #5)? Or #1089795?
Hi, I think you need to refer to both of them. From <http://fedoraproject.org/wiki/Security_Tracking_Bugs>:
"The maintainer commits the fixes, builds packages and creates an update request. He refers to both parent bug and tracking bug. Bodhi is able to identify that the bug is a tracking bug and doesn't include it in the new package announce mail."
A quick look at impact of each mktemp use:
mktemp() is used in _dump() function. As the name starting with underscore suggests, it's internal function rather than public API expected to be used by the applications using PIL / pillow.
Impact depends on the dump file format. If is format different from None and "PPM" is specified, an additional extension is appended to the name returned by mktemp(). This breaks the guarantee that the temporary file used did not exist at the time mktemp() was run, making it easier to exploit.
The _dump() can only be called by PIL / pillow with non-None format from Image.show(), a function to display image in external image viewer application, and only on Windows or Mac OS platform. On Linux, format=None is used.
The _dump() is also called from GifImagePlugin.py and JpegImagePlugin.py, but only from non-default functions to save image to a given format - _save_netpbm() and _save_cjpeg() functions respectively.
mktemp() is used in Ghostscript() to load images in post script format. The gs (from the ghostscript package) must be available.
This case seems to be the easiest to exploit. Temporary file name is exposed on the command line (see bug 1063660) of the gs command (and shell spawning it), and there's non-trivial delay between the name gets exposed, and the time gs actually creates the file.
mktemp() is used in load_djpeg(). That is undocumented API, and never called by PIL/pillow. Only applications that explicitly call it can be affected.
mktemp() is used in load(), hence this can be triggered when loading image. Exploitability should be similar to the _dump() case with format=None - chosen temporary file name is not exposed, and there's short delay between mktemp() call and file creation.
python-pillow-2.2.1-7.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
python-pillow-2.0.0-16.gitd1c6db8.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.