Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Mar 2015 08:35:16 -0500
From: Jodie Cunningham <jodie.cunningham@...il.com>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE Request: Multiple vulnerabilities in freexl 1.0.0g

Firstly, a correction to my earlier statement about the fixed release:
1.0.0i is the first release to include the patch.


On Fri, Mar 27, 2015 at 1:54 AM,  <cve-assign@...re.org> wrote:
>> #2:
> 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.

> Or does it refer to the missing "> 1024 * 1024" test in the parse_SST
> function?
>> #4:
> 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?

This vulnerability is related to the missing "> 1024 * 1024" test in
the parse_SST function.  The workbook could be crafted with a bad
shared strings table that could use up an excessive amount of memory
resources on the target system. gdb/exploitable.py also indicated
DestAvNearNull at the time of the crash.

The retcode change should benefit #3 and #4, but I don't know that it
has any role at all in preventing the vulnerabilities.

V/R,
-Jodie

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ