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] [day] [month] [year] [list]
Date: Sat, 2 Apr 2005 11:36:13 -0700
From: "Jason V. Miller" <jmiller@...urityfocus.com>
To: Steve Grubb <linux_4ever@...oo.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: bzip2 TOCTOU file-permissions vulnerability


Comments inline.

On Sun, Apr 03, 2005 at 12:44:53AM -0000, Steve Grubb wrote:
> In-Reply-To: <7389fc4b0503301338f74a428@...l.gmail.com>
> 
> >================================
> >bzip2 TOCTOU file-permissions vulnerability 
> >================================
> >
> >Software: bzip2
> >Version: 1.0.2
> >Software URL: <http://sources.redhat.com/bzip2/>
> >Platform:  Unix, Linux.
> >Vulnerability type: Time-of-Check-Time-Of-Use
> >Severity: Low, requires local attacker and badly set
> >directory permissions.
> 
> This is completely wrong. If you look at the code to bzip2.c, you'll see that it calls fopen_output_safely(). This function in turn does an
> 
> open(name,  O_WRONLY|O_CREAT|O_EXCL, S_IWUSR|S_IRUSR);
> 
> This means the file is opened with perms 0600.

File permissions don't matter when the file is located in a directory that the
attacker has write permissions to, unless the directory is sticky. This is
stated in the severity of the advisory (badly set directory permissions).

> >Vulnerable software
> >====================
> >
> >bzip2 1.0.2 and previous versions running on unix. 
> >
> >bzip2 1.0.2 compiled for Windows using lcc or MS
> >Visual C++  is not effected.
> 
> Wrong again. In fopen_output_safely, if BZ_UNIX is not set, the it resorts to fopen. Looking at the manual_3.html page, it says that on Win32 you set this define to 0. Therefore windows might be vulnerable.

This issue has nothing to do with fopen. It's the use of chmod on the
extracted file instead of using fchmod on the descriptor that was opened when
decompressing the file.

> >Vulnerability
> >============== 
> >
> >If a malicious local user has write access to a
> >directory in which a target user is using bzip2 to
> >extract or compress a file to then a TOCTOU bug can 
> >be exploited to change the permission of any file
> >belonging to that user.
> 
> Wrong. They must be logged in as that user. Remember, perms on tmp file was 0600.

Again, it doesn't matter if the directory is writable by the attacker (unless
it's sticky). This is probably why the author of the advisory stated that the
severity was low, as it does require poorly set directory permissions to be
present in order to take advantage of the weakness.

> >Fix
> >====
> >
> >Ensure that any directory which is being used by 
> >bzip2 to compress/decompress files is only writeable
> >by the user or alternatively set the sticky bit on the
> >directory's permissions
> 
> According to changelog, this was fixed in 1.0.2. So, 1.0.1 and earlier might be a problem. This report is wrong in almost all aspects.

No, it's not. Although this isn't clearly a vulnerability, the re-application
of the permissions to the extracted file could be done in a more secure
fashion, namely by calling fchmod on the extracted file's descriptor instead of
calling chmod on the path to the file. Check the behavior of BSD cp for the
"better" way of creating a new file and preserving the permissions of the
source (-p).

J.

-- 
Jason V. Miller, Threat Analyst
Symantec, Inc. - www.symantec.com
E-Mail:	jmiller@...urityfocus.com


Powered by blists - more mailing lists