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@xxxxxxxxxxxxxx>
>
> >================================
> >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@xxxxxxxxxxxxxxxxx