GNU bug report logs - #72283
Path traversal in gzip's -S option

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Alex Stumpf <gnu <at> AlexStumpf.de>
Subject: bug#72283: closed (Re: bug#72283: Path traversal in gzip's -S option)
Date: Thu, 25 Jul 2024 02:17:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#72283: Path traversal in gzip's -S option

which was filed against the gzip package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 72283 <at> debbugs.gnu.org.

-- 
72283: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=72283
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alex Stumpf <gnu <at> AlexStumpf.de>
Cc: 72283-done <at> debbugs.gnu.org
Subject: Re: bug#72283: Path traversal in gzip's -S option
Date: Wed, 24 Jul 2024 19:16:40 -0700

[Message part 3 (text/plain, inline)]

On 2024-07-24 14:59, Alex Stumpf wrote:
> It's up to you whether you consider this a fix-worthy bug,

Thanks for reporting that. It's bad behavior, and worth a fix. I 
installed the attached and am closing the bug report.

[0001-gzip-reject-suffixes-containing.patch (text/x-patch, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Alex Stumpf <gnu <at> AlexStumpf.de>
To: bug-gzip <at> gnu.org
Subject: Path traversal in gzip's -S option
Date: Wed, 24 Jul 2024 23:59:33 +0200

Hi,

I just stumbled upon a "feature" that was probably not intended with the 
-S parameter:

  $ cat /tmp/importantfile
  important content
  $ gzip -f -k -S .d/../../tmp/importantfile /etc/ld.so.conf
  $ cat /tmp/importantfile
  <gzipped content of /etc/ld.so.conf>
  $

I.e., it is possible to create/overwrite files at arbitrary locations 
(provided the user has write permission) just by using gzip parameters. 
This is not an issue for systems with regular shell access, but e.g. 
someone who sets up a restricted shell or allows execution of gzip via a 
web interface might not expect that behavior.

The command works because there is both an /etc/ld.so.conf file as well 
as an /etc/ld.so.conf.d/ directory. So the resulting filename
/etc/ld.so.conf.d/../../tmp/importantfile is a valid path.

It's up to you whether you consider this a fix-worthy bug, but I think 
it wouldn't hurt to test whether compressed and uncompressed files are 
in the same directory.

Cheers
 Alex

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.