oss-sec mailing list archives

Re: Bugs in "file" program VU#621745


From: Jan Lieskovsky <jlieskov () redhat com>
Date: Tue, 20 Mar 2012 18:11:07 +0100


Hi Kurt, vendors,

Date: Wed, 29 Feb 2012 16:54:49 -0500 (EST)
From: Kurt Seifried <kseifrie ()    hat com>
To: oss-security ()    ts openwall com
Cc: Florian Weimer <fw ()    eb enyo de>
Subject: Re: Bugs in "file" program VU#621745

On 02/29/2012 10:52 AM, Florian Weimer wrote:
* Kurt Seifried:

We recently pointed the CERT BFF at the ubiquitous "file" command
and found a few bugs.  While we've not proven the bugs to be
exploitable, we've also not ruled out the possibility that they
could be.

Fixes were committed on Feb 16, 2012:
https://github.com/glensc/file/commits/master

If any of these are security issues please let me know and I will
assign CVE #'s.

file also provides a library, libmagic.  This could lead to crashes of
server processes which use libmagic.  Debian will likely release a fix
as a security update.

Fair enough but I'd like some details before issuing CVE's, like what
are the actual security issues that have been fixed?

Based on further investigation, I am able to tell the issues here
are out-of heap-based buffer reads and / or invalid pointer dereferences
by processing various parts of CDF (Composite Document Files) header.

Out-of heap-based buffer reads:
i)   either by attempt to access field at invalid index,
ii)  or by attempt to access field out of allocated array bounds.

Invalid pointer dereferences:
iii) by attempt to access pointer value, being modified in
     a for loop cycle.

Anyway, the file executable is terminated in each case yet by attempt
to read the location, thus these seem to be able to cause just file
executable crashes.

Relevant Red Hat Bugzilla record is here:
[1] https://bugzilla.redhat.com/show_bug.cgi?id=805197

Though issues having lower impact, would it be possible to allocate
one CVE identifier to these? (one should be enough, since the reason
is always the same and the underlying code is parsing CDF file header).

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team


--
Kurt Seifried Red Hat Security Response Team (SRT)


Current thread: