[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#308783: RFC: Bug#308783: libxpm4: problems with s_popen (CAN-2004-0914)



Could I get a second opinion (or more than one) from you guys as to whether
this is actually an exploitable security problem?

I have been talking to Steve Langasek in his capacity as a Release Manager
about this, and he says if it's not an exploitable problem, then it's not
really a security issue, not really RC, and therefore not deserving of
excepting from the freeze.

Note that I cloned this bug for stable as #309143, and whatever conclusions
are reached here will probably map to that as well.

I asked Matej to follow-up with more information about this, and to contact
freedesktop.org and/or MITRE for a CAN allocation, but haven't heard
anything back from him yet.

If there's any more information I can provide, please let me know.

----- Forwarded message from Matej Vela <vela@debian.org> -----

From: Matej Vela <vela@debian.org>
To: submit@bugs.debian.org
Subject: Bug#308783: libxpm4: problems with s_popen (CAN-2004-0914)
Date: Thu, 12 May 2005 12:59:04 +0200
Message-ID: <[🔎] 20050512105900.GP14871@irb.hr>
List-Id: <debian-x.lists.debian.org>
X-Mailing-List: <debian-x@lists.debian.org> archive/latest/26382
User-Agent: Mutt/1.5.6+20040907i
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
	autolearn=no version=2.60-bugs.debian.org_2005_01_02

Package: libxpm4
Version: 4.3.0.dfsg.1-12
Severity: grave
Justification: may allow access to the accounts of users who use the package

The CAN-2004-0914 patch introduced a s_popen() function as a safe
replacement for popen().  Instead of invoking a shell, it splits
arguments on whitespace and passes the command directly to execvp(3).
However, it doesn't handle quoting or redirection, so code like

  WrFFrI.c:339:       snprintf(buf, sizeof(buf), "gzip -q > \"%s\"", filename);
  WrFFrI.c:340:       if (!(mdata->stream.file = s_popen(buf, "w")))

results in a ">" argument and superfluous quotes:

  execve("/bin/gzip", ["gzip", ">", "\"foo.gz\""], [/* 19 vars */])

This completely breaks the transparent compression and decompression.

Furthermore, since gzip processes all arguments regardless of errors, an
attacker can use filenames with whitespace to compress arbitrary files:
(xpmtest taken from <https://bugs.freedesktop.org/show_bug.cgi?id=1920>)

  # ./xpmtest crab.xpm 'fnord -v /etc/hosts.deny fnord.gz'
  w=28, h=28, cpp=2, cols=6, vmask=00000000, hotspot=0,0
  gzip: >: No such file or directory
  gzip: "fnord: No such file or directory
  /etc/hosts.deny:       -50.0% -- replaced with /etc/hosts.deny.gz
  gzip: fnord.gz": No such file or directory

The above would effectively disable TCP wrappers.  The -r option can be
used to compress whole directory trees.

s_popen() also has issues with error handling, signals, and runaway
child processes.  All of this has been fixed in X11R6.8.2, though I
don't think they're aware of the security implications (patches at
<http://ftp.x.org/pub/X11R6.8.1/patches/> are still vulnerable).

Thanks,

Matej


-- 
To UNSUBSCRIBE, email to debian-x-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


----- End forwarded message -----

-- 
G. Branden Robinson                |     Communism is just one step on the
Debian GNU/Linux                   |     long road from capitalism to
branden@debian.org                 |     capitalism.
http://people.debian.org/~branden/ |     -- Russian saying

Attachment: signature.asc
Description: Digital signature


Reply to: