After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 702182 - Gnumeric segfaults in excel_read_COLINFO on a corrupted (fuzzed) xls file
Gnumeric segfaults in excel_read_COLINFO on a corrupted (fuzzed) xls file
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export MS Excel (tm)
git master
Other Linux
: Normal critical
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2013-06-13 13:44 UTC by jutaky
Modified: 2013-06-17 05:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description jutaky 2013-06-13 13:44:11 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
  • #0 excel_read_COLINFO
    at ms-excel-read.c line 4316
  • #1 excel_read_sheet
    at ms-excel-read.c line 6649
  • #2 excel_read_BOF
    at ms-excel-read.c line 6981
  • #3 excel_read_workbook
    at ms-excel-read.c line 7071
  • #4 excel_enc_file_open
    at boot.c line 193
  • #5 excel_file_open
    at boot.c line 250
  • #6 go_plugin_loader_module_func_file_open
    at app/go-plugin-loader-module.c line 282
  • #7 go_plugin_file_opener_open
    at app/go-plugin-service.c line 685
  • #8 go_file_opener_open
    at app/file.c line 417
  • #9 workbook_view_new_from_input
    at workbook-view.c line 1272
  • #10 workbook_view_new_from_uri
    at workbook-view.c line 1332
  • #11 main
    at main-application.c line 321

--
Juha Kylmänen
Research Assistant, OUSPG
Comment 1 Morten Welinder 2013-06-13 18:17:20 UTC
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.
Comment 2 jutaky 2013-06-13 18:53:48 UTC
I am using Radamsa, an open source fuzzer from OUSPG: https://www.ee.oulu.fi/research/ouspg/Radamsa
Comment 3 Morten Welinder 2013-06-13 19:30:28 UTC
That wasn't what I meant to ask.

The question is where do the xls/ods/whatever files come from?
Comment 4 jutaky 2013-06-13 19:36:40 UTC
I google them. They are just random files from the Internet.
Comment 5 jutaky 2013-06-16 18:53:56 UTC
This issue has been assigned CVE-id CVE-2013-4607.
Comment 6 Morten Welinder 2013-06-17 00:04:07 UTC
> 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?
Comment 7 jutaky 2013-06-17 05:28:30 UTC
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