Inkscape reads .eps files from /tmp instead of the current directory

Bug #911146 reported by Alex Valavanis
272
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
High
Unassigned
inkscape (Debian)
Fix Released
Unknown

Bug Description

Forwarded from Debian:

Package: inkscape
Version: 0.48.1-2.1+b1
Severity: grave
Tags: security
Justification: user security hole

When I want to open a .eps file with something like

 inkscape file.eps

inkscape tries to open the file from /tmp instead of the current
directory (if the file doesn't exist, I get a ghostscript error from
ps2pdf, which is the same error as when ps2pdf is run manually).

According to strace, inkscape does a chdir to /tmp before running
ps2pdf on the argument, hence the problem.

The security problem is that the user A may open a file belonging
to some user B from /tmp, which can contain incorrect data, an
offensive image and so on. It can also be a symbolic link to some
protected file of user A (which may inadvertently diffused to other
users) or to some other special file that shouldn't be read, such as
/proc/<pid>/fd/0, which can make program <pid> behave incorrectly.

-- System Information:
Debian Release: wheezy/sid
 APT prefers unstable
 APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages inkscape depends on:
ii libaspell15 0.60.7~20110707-1
ii libatk1.0-0 2.2.0-2
ii libatkmm-1.6-1 2.22.6-1
ii libc6 2.13-24
ii libcairo2 1.10.2-6.2
ii libcairomm-1.0-1 1.10.0-1
ii libfontconfig1 2.8.0-3
ii libfreetype6 2.4.8-1
ii libgc1c2 1:7.1-8
ii libgcc1 1:4.6.2-9
ii libgconf2-4 3.2.3-1
ii libgdk-pixbuf2.0-0 2.24.0-2
ii libglib2.0-0 2.30.2-4
ii libglibmm-2.4-1c2a 2.30.0-2
ii libgnomevfs2-0 1:2.24.4-1
ii libgomp1 4.6.2-9
ii libgsl0ldbl 1.15+dfsg-1
ii libgtk2.0-0 2.24.8-2
ii libgtkmm-2.4-1c2a 1:2.24.2-1
ii libgtkspell0 2.0.16-1
ii liblcms1 1.19.dfsg-1+b1
ii libmagick++4 8:6.6.9.7-5+b2
ii libmagickcore4 8:6.6.9.7-5+b2
ii libpango1.0-0 1.29.4-2
ii libpangomm-1.4-1 2.28.4-1
ii libpng12-0 1.2.46-3
ii libpoppler-glib6 0.16.7-2+b1
ii libpoppler13 0.16.7-2+b1
ii libpopt0 1.16-3
ii libsigc++-2.0-0c2a 2.2.9-1.1
ii libstdc++6 4.6.2-9
ii libwpd-0.9-9 0.9.4-1
ii libwpg-0.2-2 0.2.1-1
ii libx11-6 2:1.4.4-4
ii libxml2 2.7.8.dfsg-5.1
ii libxslt1.1 1.1.26-8
ii zlib1g 1:1.2.3.4.dfsg-3

Versions of packages inkscape recommends:
ii aspell 0.60.7~20110707-1
ii imagemagick 8:6.6.9.7-5+b2
ii libwmf-bin <none>
ii perlmagick <none>
ii pstoedit 3.60-1

Versions of packages inkscape suggests:
pn dia | dia-gnome <none>
pn libgnomevfs2-extra 1:2.24.4-1
pn libsvg-perl <none>
pn libxml-xql-perl <none>
pn python 2.7.2-9
pn python-lxml <none>
pn python-numpy 1:1.5.1-3
pn python-uniconvertor <none>
pn ruby 4.8
pn ruby1.8 [ruby] 1.8.7.352-2
pn skencil <none>

-- no debconf information

CVE References

Changed in inkscape (Debian):
status: Unknown → New
Changed in inkscape (Debian):
status: New → Confirmed
su_v (suv-lp)
tags: added: eps importing
tags: added: extensions-plugins
visibility: private → public
Revision history for this message
Alex Valavanis (valavanisalex) wrote :

Note that this has been flagged as a security issue in Debian: https://security-tracker.debian.org/tracker/TEMP-0654341-9198B9

Changed in inkscape:
importance: Undecided → High
Revision history for this message
John Paul Adrian Glaubitz (glaubitz) wrote :

Please find the suggested patch by Michael Karcher <email address hidden>.

This patch adds expansion of relative file names in the filename parameter before passing it to external scripts.

Revision history for this message
John Paul Adrian Glaubitz (glaubitz) wrote :

I have also included this patch in the Debian package and uploaded it as another NMU into unstable (0.48.3.1-1.3).

Cheers,

Adrian

Changed in inkscape (Debian):
status: Confirmed → Fix Released
Revision history for this message
Salvatore Bonaccorso (carnil) wrote :
Revision history for this message
su_v (suv-lp) wrote :

> When I want to open a .eps file with something like
>
> inkscape file.eps
>
> inkscape tries to open the file from /tmp instead of the current
> directory (if the file doesn't exist, I get a ghostscript error from
> ps2pdf, which is the same error as when ps2pdf is run manually).

Opening EPS files on the command line with relative paths was broken in the previous stable releases (Inkscape 0.48 - 0.48.3.1), and only was fixed in the most recent bug fix release 0.48.4:
- Bug #695120 “cannot open relative paths using script extensions from command line”
  <https://bugs.launchpad.net/inkscape/+bug/695120>

> According to strace, inkscape does a chdir to /tmp before running
> ps2pdf on the argument, hence the problem.

AFAIU Inkscape does not changedir into /TMP - it passes the absolute path names of the temporary file copies in $TMPDIR to ps2pdf. Handling of PS/EPS files with relative paths on the command line was broken in 0.48 due to other changes which make Inkscape change directory into $XDG_CONFIG/inkscape/extensions (not $TMPDIR) before spawning the interpreter for the script extension (python in the case of PS/EPS files).

(Note: I haven't tested the proposed patch from comment #2 yet with current trunk or stable 0.48.4)

Revision history for this message
John Paul Adrian Glaubitz (glaubitz) wrote :

> AFAIU Inkscape does not changedir into /TMP - it passes the absolute path names of the temporary
> file copies in $TMPDIR to ps2pdf.

From share/extensions/run_command.py:

    # ps2pdf may attempt to write to the current directory, which may not
    # be writeable, so we switch to the temp directory first.
    try:
        os.chdir(tempfile.gettempdir())

and share/extensions/ps2pdf-ext.py:

import sys
from run_command import run

cmd = 'ps2pdf'
if (sys.argv[1] == "--dEPSCrop=true"): cmd += ' -dEPSCrop '

run((cmd+' "%s" "%%s"') % sys.argv[-1].replace("%","%%"), "ps2pdf")

It clearly changes into /tmp before running ps2pdf.

Adrian

Revision history for this message
su_v (suv-lp) wrote :

On 30/12/2012 10:27, John Paul Adrian Glaubitz wrote:>From share/extensions/run_command.py:
>
> # ps2pdf may attempt to write to the current directory, which may not
> # be writeable, so we switch to the temp directory first.
> try:
> os.chdir(tempfile.gettempdir())
(…)
> It clearly changes into /tmp before running ps2pdf.

Sorry, you are correct (I thought I did check both python modules before replying, but obviously missed that line).

Revision history for this message
su_v (suv-lp) wrote :

John Paul Adrian Glaubitz wrote:
> This patch adds expansion of relative file names in the
> filename parameter before passing it to external scripts.

AFAICT this patch is no longer required for Inkscape 0.48.4 and current trunk, since the fix for bug #695120 (combined with the later fix for bug #1022719) already does that (make sure that the relative path from the command line argument is expanded to an absolute path before being passed to the extension script).

@JazzyNico - could you test current stable (0.48.4) and trunk, and review the patch from comment #2 if it is still necessary?

Revision history for this message
John Paul Adrian Glaubitz (glaubitz) wrote :

> AFAICT this patch is no longer required for Inkscape 0.48.4

I cannot say anything regarding 0.48.4. The reason we created this patch was to be able to patch the version in Debian which is going to be included in upcoming Debian Wheezy release.

Since we're currently in freeze, new upstream packages are not allowed for testing anymore.

Cheers,

Adrian

Revision history for this message
jazzynico (jazzynico) wrote :

> @JazzyNico - could you test current stable (0.48.4) and trunk, and review the patch from comment #2 if it is still necessary?

AFAICT, 0.48.4 and trunk are no longer affected by bug #695120 and the regression (bug #1022719) is fixed.
But the patch looks more elegant than the one we applied, and I would be interesting to test it.

Revision history for this message
John Paul Adrian Glaubitz (glaubitz) wrote :

> AFAICT, 0.48.4 and trunk are no longer affected by bug #695120 and the regression (bug #1022719) is fixed.
> But the patch looks more elegant than the one we applied, and I would be interesting to test it.

The patch by Michael Karcher actually fixes both bug #695120 and avoids the regression bug #1022719 introduced by the fix for bug #695120. Both patches in bug #695120 and bug #1022719 can therefore be replaced with this single patch.

Michael's patch relies on GLib for testing for relative pathnames and building an absolute one if necessary. Thus, there is no need to worry about (invalid) pathnames and URLs since everything is handled by GLib. The patches that have been applied so far duplicate the code in GLib.

Cheers,

Adrian

Revision history for this message
jazzynico (jazzynico) wrote :

Patch that removes the previous corrections and apply the new code to the trunk (created with revision 11998).

Revision history for this message
jazzynico (jazzynico) wrote :

New patch tested successfully (not a big surprise!) on Crunchbang Waldorf (based on Debian testing), Inkscape trunk revision 11998.

Also tested on Windows XP, same Inkscape revision. Bug #695120 is fixed but unfortunately the regression (bug #1022719) is not, and the URL fails to open with the following error message:

** (inkscape.exe:1308): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): assertion `Inkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed

Revision history for this message
su_v (suv-lp) wrote :

> but unfortunately the regression (bug #1022719) is not

Hmm, I thought this never worked on Windows before anyway (hence to be tracked in a separate report - bug #1027914, as feature request)?

Revision history for this message
su_v (suv-lp) wrote :

Confirmed after quick test with PostScript file (using relative path) and URL on the command line:
Patch '1022719-NewAndUndoOld.diff' with current trunk (r11998) works with regular (linux-style) builds on OS X 10.7.4, too.
(dependencies: GTK+/X11 2.24.13, glib 2.32.4; GTK+/Quartz 2.24.15, glib 2.34.3)

Revision history for this message
John Paul Adrian Glaubitz (glaubitz) wrote :

> Hmm, I thought this never worked on Windows before anyway (hence to be tracked in a separate report - bug #1027914, as
> feature request)?

Well, I guess that's something that can be easily verified by installing an older version (~0.47.x) on Windows XP and Windows 7.

It would actually be interesting to know whether this bug is specific to Windows XP or applies to newer versions of Windows as well.

Adrian

Revision history for this message
jazzynico (jazzynico) wrote :

I confirm it didn't work on XP with the trunk and older versions (tested with 0.45.1, 0.46 and 0.47).
Not specific to XP. It also fails with Seven (tested with the trunk only).

> tracked in a separate report - bug #1027914

Well, I even completely forgot that report...

Then OK, I guess it's safe to remove the old patch and commit the new one (maybe only in the trunk for now, and later backport to the branch).

Revision history for this message
jazzynico (jazzynico) wrote :

Fixed in the trunk with the new patch from Michael Karcher, revision 12127.

Changed in inkscape:
milestone: none → 0.49
status: New → Fix Committed
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.