Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ