Bug 924849 - (CVE-2015-2753) VUL-0: CVE-2015-2753 CVE-2015-2754 CVE-2015-2776: freexl -- security update
(CVE-2015-2753)
VUL-0: CVE-2015-2753 CVE-2015-2754 CVE-2015-2776: freexl -- security update
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other openSUSE 13.2
: P3 - Medium : Normal
: ---
Assigned To: Marcus Meissner
Security Team bot
https://smash.suse.de/issue/115285/
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-03-30 07:05 UTC by Marcus Meissner
Modified: 2015-05-22 09:37 UTC (History)
1 user (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2015-03-30 07:05:41 UTC
CVE-2015-2753

thread starting here:
http://seclists.org/oss-sec/2015/q1/1004

 From: Jodie Cunningham <jodie.cunningham () gmail com>
Date: Tue, 24 Mar 2015 19:27:21 -0500

Hi,

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:
https://www.gaia-gis.it/fossil/freexl/fdiff?v1=2e167b337481dda3&v2=61618ce51a9b0c15&sbs=1

FreeXL 1.0.1 itself has been released here:
http://www.gaia-gis.it/gaia-sins/freexl-1.0.1.tar.gz

To reproduce:
./test_xl $reproducer


#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

#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

#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

#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


Regards,
-Jodie Cunningham
Comment 1 Marcus Meissner 2015-03-30 07:07:32 UTC
-----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
Comment 2 Marcus Meissner 2015-03-30 07:07:56 UTC
        #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
Comment 3 Marcus Meissner 2015-03-30 07:08:30 UTC
Factory only. Just upgrade to current version.
Comment 4 Swamp Workflow Management 2015-03-30 22:00:28 UTC
bugbot adjusting priority
Comment 5 Marcus Meissner 2015-05-22 09:37:26 UTC
1.0.1 was released