Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Mar 2015 02:54:17 -0400 (EDT)
Subject: Re: CVE Request: Multiple vulnerabilities in freexl 1.0.0g

Hash: SHA1

> I found multiple issues in the library FreeXL 1.0.0g.
> The vendor has corrected these issues in FreeXL 1.0.1 , and a diff for
> the four issues is available here:

We don't feel that this has information in a usable format for making
all of the CVE assignments. Listing four flaw descriptions with four
reproducers does not necessarily imply a specific number of CVE IDs.
We are not going to run the product with the reproducers to gather
additional information.

We have:

> #1:  A flaw was found in the way FreeXL reads sectors from the input
> file.  A specially crafted file could possibly result in stack
> corruption near freexl.c:3752.
> Reproducer:

Here, it seems very likely that what is meant is the missing "if
(workbook->sector_end <= (workbook->p_in - workbook->sector_buf))"
test in the unpatched code. In other words, the product did not verify
that the calculation of the unsigned "chunk" value occurred as

Use CVE-2015-2753.

> #3: A flaw was found in the way FreeXL handles a premature EOF. A
> specially crafted input file could possibly result in stack corruption
> near freexl.c:1131
> Reproducer:

This refers to the missing "if ((workbook->p_in -
workbook->fat->miniStream) + workbook->record_size > (int)
workbook->size)" test in the unpatched code (i.e., the test with the
"unexpected EOF" comment in the patched code).

Use CVE-2015-2754.

> #2: A flaw was found in the function allocate_cells(). A specially
> crafted file with invalid workbook dimensions could possibly result in
> stack corruption near freexl.c:1074
> Reproducer:

Does this refer to the missing "== NULL" tests within the
allocate_cells function? Is a NULL pointer dereference going to occur
before the code reaches a point where there can be stack corruption?

Or does it refer to the missing "> 1024 * 1024" test in the parse_SST

> #4: FreeXL 1.0.0g did not properly check requests for workbook memory
> allocation. A specially crafted input file could cause a Denial of
> Service, or possibly write onto the stack.
> Reproducer (ulimit -Sv 128000):

Does this refer to the change from the "return ret;" code to the
"errcode = ret; goto stop;" code?

Or does it refer to one of the two possibilities listed above for #2?

"check requests for workbook memory allocation" could also conceivably
refer to tests of the return value of malloc, but no such tests were
added in the patch.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


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.