Vulnerabilities > CVE-2017-2919 - Out-of-bounds Write vulnerability in multiple products
Attack vector
NETWORK Attack complexity
MEDIUM Privileges required
NONE Confidentiality impact
PARTIAL Integrity impact
PARTIAL Availability impact
PARTIAL Summary
An exploitable stack based buffer overflow vulnerability exists in the xls_getfcell function of libxls 1.3.4. 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
Vulnerable Configurations
| Part | Description | Count |
|---|---|---|
| Application | 1 | |
| OS | 1 |
Common Weakness Enumeration (CWE)
Nessus
NASL family Debian Local Security Checks NASL id DEBIAN_DSA-4173.NASL description Marcin Noga discovered multiple vulnerabilities in readxl, a GNU R package to read Excel files (via the integrated libxls library), which could result in the execution of arbitrary code if a malformed spreadsheet is processed. last seen 2020-06-01 modified 2020-06-02 plugin id 109065 published 2018-04-17 reporter This script is Copyright (C) 2018 and is owned by Tenable, Inc. or an Affiliate thereof. source https://www.tenable.com/plugins/nessus/109065 title Debian DSA-4173-1 : r-cran-readxl - security update NASL family Gentoo Local Security Checks NASL id GENTOO_GLSA-202003-64.NASL description The remote host is affected by the vulnerability described in GLSA-202003-64 (libxls: Multiple vulnerabilities) Multiple vulnerabilities have been discovered in libxls. Please review the CVE identifiers referenced below for details. Impact : A remote attacker could entice a user to process a specially crafted Excel file using libxls, possibly resulting in execution of arbitrary code with the privileges of the process or a Denial of Service condition. Workaround : There is no known workaround at this time. last seen 2020-04-04 modified 2020-03-31 plugin id 135019 published 2020-03-31 reporter This script is Copyright (C) 2020 and is owned by Tenable, Inc. or an Affiliate thereof. source https://www.tenable.com/plugins/nessus/135019 title GLSA-202003-64 : libxls: Multiple vulnerabilities
Seebug
| bulletinFamily | exploit |
| description | ### Summary An exploitable stack based buffer overflow vulnerability exists in the xls_getfcell function of libxls 1.3.4. 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 libxls 1.3.4 ### Product URLs http://libxls.sourceforge.net/ ### 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-121: Stack-based Buffer Overflow ### Details libxls is a C library supported on windows, mac, cygwin which can read Microsoft Excel File Format ( XLS ) files. The library is used by the readxl package of the Microsoft R programming language. A stack based buffer overflow is present in the xls_getfcell function. Let's take a look at the vulnerable code: ``` Line 377 char* xls_getfcell(xlsWorkBook* pWB,struct st_cell_data* cell) Line 378 { Line 379 struct st_xf_data* xf; Line 380 char ret[10240]; Line 381 Line 382 (...) Line 383 //LABELSST Line 384 switch (cell->id) Line 385 { Line 386 case 0x0FD: Line 387 sprintf(ret,"%s",pWB->sst.string[cell->l].str); Line 388 break; ``` As the comment at `line 383` states, this fragment of code is responsible for parsing `LabelSst` cells. According to the definition in the `2.4.149` LabelSst in the MS-XLS 6.0 documentation : ``` > The LabelSst record specifies a cell that contains a string. > cell (6 bytes): A Cell structure that specifies the cell containing the string from the shared string table. > isst (4 bytes): An unsigned integer that specifies the zero-based index of an element in the array of XLUnicodeRichExtendedString structure in the rgb field of the SST record in this Workbook Stream ABNF that specifies the string contained in the cell. MUST be greater than or equal to zero and less than the number of elements in the rgb field of the SST record. ``` The cell which causes an overflow in our PoC is located at offset : 0x11957 Its values look as follows: ``` p/x *cell $2 = {id = 0xfd, row = 0x0, col = 0x0, xf = 0xf, d = 0x0, l = 0xf9, str = 0x6100000000000000, ishiden = 0x0, width = 0x0, colspan = 0x0, rowspan = 0x0} ``` Based on the cell's `isst` field which in code is represented as the `l` field, the `XLUnicodeRichExtendedString` is located in the `SST` record. We see that operation performed at `line 387` is a classic stack based buffer overflow, because as we can see `ret` array has fixed size `10240`, where string coming from `XLUnicodeRichExtendedString` SST record can exceed that size and cause an overflow. ``` (rr) p pWB->sst.string[0xf9] $3 = {str = 0x143fd40 "prueba de exportaci\363n prueba de exportaci\363nprueba de exportaci\363nprueba de exportaci\363nprueba de exportaci\363nprueba de exportaci\363nprueba de exportaci\363nprueba de exportaci\363nprueba de exportaci\363nprueba de "...} ``` ### Crash Information ``` Reading symbols from ./xls2csv...done. (gdb) r Starting program: /home/icewall/bugs/libxls-0.2.0/build/bin/xls2csv ./crashes/16ae3756c8a7d987860ec5abe5fa5600 Program received signal SIGSEGV, Segmentation fault. __strcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:241 241 ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S: No such file or directory. (gdb) bt 20 #0 __strcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:241 #1 0x00007ffff7bce9e2 in xls_getfcell (pWB=0x603010, cell=0x62a1d9) at xlstool.c:389 #2 0x2065642061626575 in ?? () #3 0x636174726f707865 in ?? () #4 0x62657572706ef369 in ?? () #5 0x7078652065642061 in ?? () #6 0x6ef369636174726f in ?? () #7 0x6420616265757270 in ?? () #8 0x74726f7078652065 in ?? () #9 0x7572706ef3696361 in ?? () #10 0x6520656420616265 in ?? () #11 0x69636174726f7078 in ?? () #12 0x6162657572706ef3 in ?? () #13 0x6f70786520656420 in ?? () #14 0x706ef36963617472 in ?? () #15 0x6564206162657572 in ?? () #16 0x6174726f70786520 in ?? () #17 0x657572706ef36963 in ?? () #18 0x7865206564206162 in ?? () #19 0xf369636174726f70 in ?? () (More stack frames follow...) ``` ### Timeline * 2017-08-29 - Vendor Disclosure * 2017-11-15 - Public Release |
| id | SSV:96901 |
| last seen | 2017-12-25 |
| modified | 2017-11-29 |
| published | 2017-11-29 |
| reporter | Root |
| title | libxls xls_getfcell Code Execution Vulnerability(CVE-2017-2919) |
Talos
| id | TALOS-2017-0426 |
| last seen | 2019-05-29 |
| published | 2017-11-15 |
| reporter | Talos Intelligence |
| source | http://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0426 |
| title | libxls xls_getfcell Code Execution Vulnerability |