Date: Fri, 27 Mar 2015 19:48:01 -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 >> #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. > This vulnerability is related to the missing "> 1024 * 1024" test in > the parse_SST function. Use CVE-2015-2776. >>> #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 >> Does this refer to the missing "== NULL" tests within the >> allocate_cells function? > Yes >> Is a NULL pointer dereference going to occur >> before the code reaches a point where there can be stack corruption? > I don't believe so. It looks like these are initialized as NULL, and > if they are still NULL at this point in execution then we assume the > input file was malformed and exit with the appropriate return code. In that case, we don't know what vulnerability you mean for #2. Between the unpatched code and the patched code, the only change in the allocate_cells function is the addition of checks for whether workbook or workbook->active_sheet is NULL. In the unpatched code, if either of these were NULL, workbook->active_sheet->rows would result in a NULL pointer dereference. As far as we know, this outcome is not typically described as "stack corruption." If the design of the allocate_cells function was supposed to anticipate that callers might provide a NULL value for workbook or workbook->active_sheet, then the unpatched code had a vulnerability in the allocate_cells function that might loosely be described as a "NULL pointer dereference vulnerability." We think you may mean that, in some cases, stack corruption has occurred because of invalid workbook dimensions before the allocate_cells function is called. In some or all of these cases, a side effect of the stack corruption is that either workbook or workbook->active_sheet is NULL. The patched code, instead of preventing the stack corruption (or detecting the stack corruption before calling allocate_cells), chooses to use these "== NULL" tests to infer that stack corruption has occurred. Is this correct? (The concern here is that this would not typically be described as "A flaw was found in the function allocate_cells()." It might instead be described as something like "a missed opportunity to use the function allocate_cells() to address stack corruption elsewhere." Maybe this is a subtle distinction but it, in general, affects both the meaning of the CVE and the usefulness of doing some additional types of security research on the FreeXL code.) - -- 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) iQEcBAEBAgAGBQJVFetiAAoJEKllVAevmvmsljMH/3NyPgTVznHzMQ3VFi1x8IIL HLbNwB+sGlU6mgN4lnuyLf2rMQVpYHeXbFo3A7oXzBQF4OctEBFv/9Qa2GRcL6N7 EYBtFOYZkPGRy4bDT5ucgUW79ZTSkwHCZM3bTbmj/FceoOZWCu84GwhuspLDa1Wt lSzwkwidfuAu83pBj2UiQPmxjE6dKsriYOfZL8Ru3ZstbO80dmxXgZLQ28D58LaY kXV0D8GdO/i1Uwmmei1D6jzkysyZKm2boV4cEiUmJ6t6oS5hJZeD/KG/+IHPyGrg vhMVAF10dU/nxCk3GBlE3jXvq9CzI1p53e8bT9pgDkx93fvNY6Vj8rnrFdS7vTM= =IKyu -----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.