bugtraq - Re: gzip TOCTOU file-permissions vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20050414161105.GA11934@sophic.org>
Date: Thu, 14 Apr 2005 12:11:06 -0400
From: Derek Martin <code@...zashack.org>
To: bugtraq@...urityfocus.com
Cc: support@...p.org
Subject: Re: gzip TOCTOU file-permissions vulnerability

On Thu, Apr 14, 2005 at 09:27:11AM -0600, Mark Senior wrote:
> > From: Derek Martin [mailto:code@...zashack.org] 
> > Sent: April 13, 2005 08:50

If you can, I might suggest configuring your e-mail client not to
attribute e-mail addresses in replies (at least to mailing lists)...
It doesn't solve the problem by any means, but it reduces the
availability of e-mail addresses in web archives which can be
harvested.  Mailing lists can easily be configured to obscure
addresses in their web archives, but often this doesn't extend to
addresses posted in the body of the e-mail itself...  :)

> > The open() call is at fault here.  If instead of being called 
> > with a mode of RW_USER, it is called with the final intended 
> > access mode, there is no need to later call chmod(), and the 
> > problem is averted.
> 
> One wrinkle - if the file is not intended to have user write permission
> on it, and gzip (unzip/cpio/pax...) initially created it with the
> intended permissions, there would be no way to then write the file.

Excellent point, which I overlooked.  So the patch which I posted
(whether it shows up on bugtraq is an entirely different question...)
is worthless.  Sigh.  ;-)  I momentarily confused root's ability to
write to any file regardless of access permissions with a fictitious
user ability to write to their own files, regarless of write access.
Too bad... that ability would make for a nice solution to the problem!
[sheepish grin]

> The problem, to my understanding, is that the program opens the file by
> name, then closes it, and then chmod's it, again referring to it by
> name.  During which time, as you pointed out, we could be dealing with a
> different inode.

Yeah, that's the problem.

> If the program kept the file open, and used fchmod to change its
> permissions, referring to it by file descriptor, you could be more sure
> that it was the same inode it had just been writing to.

That would do the trick.  The question becomes one of how portable
fchmod() is...  My programming experience is unfortunately limited to
platforms which are pretty POSIX compliant, so I can't even guess...

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

Content of type "application/pgp-signature" skipped