CVE-2017-2923

Summary

An exploitable heap based buffer overflow vulnerability exists in the read_biff_next_record function of FreeXL 1.0.3. A specially crafted XLS file can cause a memory corruption resulting in remote code execution. An attacker can send malicious XLS file to trigger this vulnerability.

Tested Versions

freexl 1.0.3

Product URLs

https://www.gaia-gis.it/fossil/freexl/index

CVSSv3 Score

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CWE

CWE-122: Heap-based Buffer Overflow

Details

FreeXL is a C library which can read Microsoft Excel File Format ( XLS ) files. The library is used by the SpatiaLite open source library. A heap-based buffer overflow appears in the read_biff_next_record function. The vulnerability appears in a situation when a BIFF record size is bigger than workbook->record field. The following code contains the vulnerability:

freexl_internals.h Line 278 unsigned char record[8224]; /* current record */ freexl.c Line 3723 static int Line 3724 read_biff_next_record (biff_workbook * workbook, int swap, int *errcode) Line 3725 { (...) Line 3772 /* fetching record-type and record-size */ Line 3773 memcpy (record_type.bytes, workbook->p_in, 2); Line 3774 workbook->p_in += 2; Line 3775 memcpy (record_size.bytes, workbook->p_in, 2); Line 3776 workbook->p_in += 2; (...) Line 3808 while (already_done < workbook->record_size) Line 3809 { Line 3810 /* reading a further sector */ Line 3811 ret = read_cfbf_next_sector (workbook, errcode); Line 3812 if (ret == -1) Line 3813 return -1; /* EOF found */ Line 3814 if (ret == 0) Line 3815 return 0; Line 3816 chunk = workbook->record_size - already_done; Line 3817 if (chunk <= workbook->fat->sector_size) Line 3818 { Line 3819 /* ok, finished: whole record reassembled */ Line 3820 memcpy (workbook->record + already_done, workbook->p_in, Line 3821 chunk); Line 3822 workbook->p_in += chunk; Line 3823 goto record_done; Line 3824 } Line 3825 /* record still spanning on the following sector */ Line 3826 memcpy (workbook->record + already_done, workbook->p_in, Line 3827 workbook->fat->sector_size); Line 3828 workbook->p_in += workbook->fat->sector_size; Line 3829 already_done += workbook->fat->sector_size; Line 3830 }

At line 3775 the record_size is read directly from the file, which is used to control the loop at line 3808. Then at lines 3820 and 3826 data will be copied into the record which has a fixed size of 8224. Since there are no checks to ensure that the record_size is smaller than this declared value, this will result in a heap-based buffer overflow.

Crash Information

icewall@ubuntu:~/bugs/freexl-1.0.3/bin$ valgrind ./test_xl ./crashes/ef69e246113c046810b7ef908cc7a09f ==99598== Memcheck, a memory error detector ==99598== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==99598== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==99598== Command: ./test_xl ./crashes/ef69e246113c046810b7ef908cc7a09f ==99598== ==99598== Invalid write of size 2 ==99598== at 0x4C32723: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==99598== by 0x4E43F66: read_biff_next_record (freexl.c:3826) ==99598== by 0x4E448A7: common_open (freexl.c:4102) ==99598== by 0x4E44B39: freexl_open (freexl.c:4202) ==99598== by 0x400C3B: main (test_xl.c:84) ==99598== Address 0x572b128 is 0 bytes after a block of size 65,768 alloc'd ==99598== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==99598== by 0x4E3D4E8: alloc_workbook (freexl.c:1193) ==99598== by 0x4E44720: common_open (freexl.c:4037) ==99598== by 0x4E44B39: freexl_open (freexl.c:4202) ==99598== by 0x400C3B: main (test_xl.c:84) ==99598== ==99598== Invalid read of size 8 ==99598== at 0x50BDF20: fseek (fseek.c:35) ==99598== by 0x4E4394A: read_cfbf_sector (freexl.c:3666) ==99598== by 0x4E43AC5: read_cfbf_next_sector (freexl.c:3701) ==99598== by 0x4E43E9E: read_biff_next_record (freexl.c:3811) ==99598== by 0x4E448A7: common_open (freexl.c:4102) ==99598== by 0x4E44B39: freexl_open (freexl.c:4202) ==99598== by 0x400C3B: main (test_xl.c:84) ==99598== Address 0x8670017086708 is not stack'd, malloc'd or (recently) free'd ==99598== ==99598== ==99598== Process terminating with default action of signal 11 (SIGSEGV) ==99598== General Protection Fault ==99598== at 0x50BDF20: fseek (fseek.c:35) ==99598== by 0x4E4394A: read_cfbf_sector (freexl.c:3666) ==99598== by 0x4E43AC5: read_cfbf_next_sector (freexl.c:3701) ==99598== by 0x4E43E9E: read_biff_next_record (freexl.c:3811) ==99598== by 0x4E448A7: common_open (freexl.c:4102) ==99598== by 0x4E44B39: freexl_open (freexl.c:4202) ==99598== by 0x400C3B: main (test_xl.c:84) ==99598== Invalid read of size 8 ==99598== at 0x50C4193: _IO_flush_all_lockp (genops.c:786) ==99598== by 0x50C4329: _IO_cleanup (genops.c:951) ==99598== by 0x51BC338: __libc_freeres (in /lib/x86_64-linux-gnu/libc-2.23.so) ==99598== by 0x4A2868C: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so) ==99598== Address 0x2000f0064001a is not stack'd, malloc'd or (recently) free'd ==99598== ==99598== ==99598== Process terminating with default action of signal 11 (SIGSEGV) ==99598== General Protection Fault ==99598== at 0x50C4193: _IO_flush_all_lockp (genops.c:786) ==99598== by 0x50C4329: _IO_cleanup (genops.c:951) ==99598== by 0x51BC338: __libc_freeres (in /lib/x86_64-linux-gnu/libc-2.23.so) ==99598== by 0x4A2868C: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so) ==99598== ==99598== HEAP SUMMARY: ==99598== in use at exit: 114,272 bytes in 401 blocks ==99598== total heap usage: 403 allocs, 2 frees, 114,432 bytes allocated ==99598== ==99598== LEAK SUMMARY: ==99598== definitely lost: 4,096 bytes in 1 blocks ==99598== indirectly lost: 0 bytes in 0 blocks ==99598== possibly lost: 0 bytes in 0 blocks ==99598== still reachable: 110,176 bytes in 400 blocks ==99598== suppressed: 0 bytes in 0 blocks ==99598== Rerun with --leak-check=full to see details of leaked memory ==99598== ==99598== For counts of detected and suppressed errors, rerun with: -v ==99598== ERROR SUMMARY: 74 errors from 3 contexts (suppressed: 0 from 0) Segmentation fault (core dumped)

Timeline

2017-09-06 - Vendor Disclosure

2017-09-11 - Public Release