Re: CVE Request: Multiple vulnerabilities in freexl 1.0.0g

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
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:

  https://www.gaia-gis.it/fossil/freexl/fdiff?v1=2e167b337481dda3&v2=61618ce51a9b0c15&sbs=1
  https://www.gaia-gis.it/fossil/freexl/artifact/61618ce51a9b0c15

> #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: https://www.dropbox.com/s/3htzndywvtmomlx/freexl_9f74b0e8?dl=0

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
expected.

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: https://www.dropbox.com/s/66srfory903w6cl/freexl_d7273f72?dl=0

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: https://www.dropbox.com/s/dcnbbntf7lp03yn/freexl_c9be2aa7?dl=0

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
function?


> #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):
> https://www.dropbox.com/s/gh61gzaf8jj30hj/freexl_6889d18b?dl=0

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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJVFP2TAAoJEKllVAevmvmsEg0H/Ar1L1wjmjxYJNCLNEUCrVXG
aAdaTbufStUIy3LSG66MPklDClK3xwlS73Sor04ZpOybMbR2NFdTipwGOlufFmk0
GsgPvl9J7HgKtFNUyppvvdu+NCjBSuKhBKLuTcnIDLFborD8XHWlsl4fwIS+WpKM
djAVpq9lT4X2gevZXU+yxbalpYSIlitOtkIdQuydaU4G/914A1o/CZre9Efn3jAZ
sYXQr8aZLzkCjzj/y/pINlvySQ9zwzzYnG1VjYuNsv15+JdiTT0ZSHZB6it4UQ5k
rZI1n0dH5gHrlv/Aq9kzr1OjBFwTienVH0nbSb79DKkGr1Rr49KYsRh56WbMNsw=
=Vze4
-----END PGP SIGNATURE-----