Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Mar 2012 18:11:07 +0100
From: Jan Lieskovsky <>
Subject: Re: Bugs in "file" program VU#621745

Hi Kurt, vendors,

> Date: Wed, 29 Feb 2012 16:54:49 -0500 (EST)
> From: Kurt Seifried <>
> To:
> Cc: Florian Weimer <>
> 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:
>>> 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:

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)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.