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.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.