Date: Fri, 27 Mar 2015 02:54:17 -0400 (EDT) From: cve-assign@...re.org To: jodie.cunningham@...il.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE Request: Multiple vulnerabilities in freexl 1.0.0g -----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-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ