GNOME Bugzilla – Bug 702182
Gnumeric segfaults in excel_read_COLINFO on a corrupted (fuzzed) xls file
Last modified: 2013-06-17 05:28:30 UTC
Gnumeric segfaults in excel_read_COLINFO on a corrupted (fuzzed) xls file. Affected versions (at least): git 20130613 and 1.12.2 Test case: http://jutaky.com/fuzzing/gnumeric_case_9122_11395.xls Program received signal SIGSEGV, Segmentation fault. 0x00007fffdf54d4d7 in excel_read_COLINFO (q=0x8354f0, esheet=0x85c000) at ms-excel-read.c:4316 4316 guint16 const firstcol = GSF_LE_GET_GUINT16 (q->data); (gdb) bt
+ Trace 232046
-- Juha Kylmänen Research Assistant, OUSPG
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report. Are these files coming from a corpus that is generally available? Clearly our own fuzz testing is missing stuff.
I am using Radamsa, an open source fuzzer from OUSPG: https://www.ee.oulu.fi/research/ouspg/Radamsa
That wasn't what I meant to ask. The question is where do the xls/ods/whatever files come from?
I google them. They are just random files from the Internet.
This issue has been assigned CVE-id CVE-2013-4607.
> This issue has been assigned CVE-id CVE-2013-4607. Why? We hit a null pointer and crash. Where does it become a security concern?
I contacted Mitre for an opinion regarding the issues and they assigned these identifiers. As far as I know the reasoning is possibility for data loss via crash. Similar way LibreOffice had last year I assume: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4233