CVSS2
Attack Vector
NETWORK
Attack Complexity
LOW
Authentication
NONE
Confidentiality Impact
PARTIAL
Integrity Impact
PARTIAL
Availability Impact
PARTIAL
AV:N/AC:L/Au:N/C:P/I:P/A:P
EPSS
Percentile
82.7%
**Title:**SAP LZC/LZH Compression Multiple Vulnerabilities
**Advisory ID:**CORE-2015-0009
Advisory URL:<https://www.coresecurity.com/core-labs/advisories/sap-lzc-lzh-compression-multiple-vulnerabilities>
**Date published:**2015-05-12
**Date of last update:**2015-05-12
**Vendors contacted:**SAP
**Release mode:**Coordinated release
**Class:**Out-of-bounds Write [CWE-787], Out-of-bounds Read [CWE-125]
**Impact:**Denial of service
**Remotely Exploitable:**Yes
**Locally Exploitable:**Yes
CVE Name:CVE-2015-2282, CVE-2015-2278
SAP products make use of a proprietary implementation of the Lempel-Ziv-Thomas (LZC) adaptive dictionary compression algorithm and the Lempel-Ziv-Huffman (LZH) compression algorithm [1] . These compression algorithms are used across several SAP products and programs. Vulnerabilities were found in the decompression routines that could be triggered in different scenarios, and could lead to execution of arbitrary code and denial of service conditions.
Other products and versions might be affected, but they were not tested.
SAP published the following Security Notes:
They can be accessed by SAP clients in their Support Portal [14].
Developers who used the Open Source versions of MaxDB 7.5 and 7.6 for their tools should contact SAP.
This vulnerability was discovered and researched by Martin Gallo from Core Security Consulting Services. The publication of this advisory was coordinated by JoaquΓn RodrΓguez Varela from Core Advisories Team.
SAP products make use of LZC and LZH algorithms for compressing in-transit data for different services (Diag protocol, RFC protocol, MaxDB protocol) and for distributing files (SAPCAR program). The implementation of this algorithm was also included in Open Source versions of MaxDB 7.5 and 7.6 [2], and used on multiple Open Source security-related programs [3][4][5][6][7][8][9][10].
The code that handles the decompression of LZC and LZH compressed data is prone to two memory corruption vulnerabilities, as described below.
The vulnerability [CVE-2015-2282] is caused by an out-of-bounds write to a stack buffer used by the decompression routine to write the output characters.
The following snippet of code shows the vulnerable function [file vpa106cslzc.cpp in the MaxDB source code [11]. This piece of code can be reached by decompressing a specially crafted buffer.
[..] int CsObjectInt::CsDecomprLZC (SAP_BYTE * inbuf, SAP_INT inlen, SAP_BYTE * outbuf, SAP_INT outlen, SAP_INT option, SAP_INT * bytes_read, SAP_INT * bytes_written) [..] /* Generate output characters in reverse order ...................*/ while (code >= 256) { *stackp++ = TAB_SUFFIXOF(code); OVERFLOW_CHECK code = TAB_PREFIXOF(code); } [..]
Note that the βcodeβ variable contains an attacker controlled value, resulting in a stack overflow if the value is greater than 256 and the value for that code in the prefix table is also greater than 256. Itβs possible to fill in the stack with arbitrary values by controlling the values stored in the prefix and suffix tables.
Itβs also worth mentioning that the above code includes a macro for performing some bounds checks on the stack pointer (βOVERFLOW_CHECKβ). However, the check implemented by this macro is not sufficient for avoiding this vulnerability and also could lead to fault conditions when decompressing valid buffers. Moreover, vulnerable products and programs were built without this macro enabled (βCS_STACK_CHECKβ macro not defined at the time of compilation).
The vulnerability [CVE-2015-2278] is caused by an out-of-bounds read of a buffer used by the decompression routine when performing look-ups of non-simple codes.
The following piece of code shows the vulnerable function [file vpa108csulzh.cpp in the MaxDB source code [12]. This piece of code can be reached by decompressing a specially crafted buffer.
[..] int CsObjectInt::BuildHufTree ( unsigned * b, /* code lengths in bits (all assumed <= BMAX) */ unsigned n, /* number of codes (assumed <= N_MAX) */ unsigned s, /* number of simple-valued codes (0..s-1) */ int * d, /* list of base values for non-simple codes */ int * e, /* list of extra bits for non-simple codes */ HUFTREE **t, /* result: starting table */ int * m) /* maximum lookup bits, returns actual */ [..] if (p >= v + n) { r.e = INVALIDCODE; /* out of values--invalid code */ } else if (*p < s) { /* 256 is end-of-block code */ r.e = (unsigned char)(*p < 256 ? LITCODE : EOBCODE); r.v.n = (unsigned short) *p; /* simple code is just the value*/ p++; } else { r.e = (unsigned char) e[*p - s]; /*non-simple,look up in lists*/ r.v.n = (unsigned short) d[*p - s]; p++; } [..]
The βeβ and βdβ arrays are indexed with the value of β*p - sβ which is an attacker-controlled value. When the code is reached, this results in an out-of-bounds read access.
The vulnerabilities affect a varied range of products and programs. The attack scenarios differ based on the way each product makes use of the compression libraries. At very least the following scenarios can be identified:
SAP Netweaver services like Dispatcher or Gateway handle compressed requests coming from the different clients connecting to them. A remote unauthenticated attacker might be able to connect to the aforementioned services and trigger the vulnerabilities by sending specially crafted packets.
An attacker might be able to perform client-side attacks against users of the affected programs that handle compressed data. For instance, an attacker might send a specially crafted .CAR or .SAR archive file aimed at being decompressed using the SAPCAR tool, or mount a rogue SAP server offering Dispatcher and entice users to connect to this malicious server using SAP GUI.
As most of the services affected by these issues are not encrypted by default, an attacker might be able to perform a man-in-the-middle attack and trigger the vulnerabilities by injecting malicious packets within the communication.
The LZC and LZH compression algorithm routines are statically compiled in the different binaries of the affected products and programs. Itβs possible to check if a binary includes these functions by looking at whether the algorithmβs constants are used in the program.
The following Radare [13] command can be used to check if a binary file includes the mentioned constants:
$ rafind2 -x fffefcf8f0e0c080 -x 0103070f1f3f7fff <binary_file>
Example output:
$ rafind2 -X -x fffefcf8f0e0c080 -x 0103070f1f3f7fff SAPCAR64 SAPCAR64: 000 @ 0x1082c1 offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0x001082c1 0103 070f 1f3f 7fff fffe fcf8 f0e0 c080 .....?.......... 0x001082d1 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x001082e1 0000 0000 0000 0000 0000 0000 0000 0004 ................ 0x001082f1 0000 0004 0000 0010 0000 0000 0000 0006 ................ 0x00108301 0000 0008 0000 0010 0000 0000 0000 ..............
[1] <http://en.wikipedia.org/wiki/LZ77_and_LZ78>.
[2] <ftp://ftp.sap.com/pub/maxdb/current/7.6.00/>.
[3] <http://conus.info/utils/SAP_pkt_decompr.txt>.
[4] <https://github.com/sensepost/SAPProx>.
[5] <https://github.com/sensepost/SapCap>.
[6] <https://github.com/CoreSecurity/pysap>.
[7] <https://github.com/CoreSecurity/SAP-Dissection-plug-in-for-Wireshark>.
[8] <https://github.com/daberlin/sap-reposrc-decompressor>.
[9] <https://labs.mwrinfosecurity.com/tools/sap-decom/>.
[10] <http://www.oxid.it/cain.html>.
[11] <http://maxdb-7.5.00.sourcearchive.com/documentation/7.5.00.44-2/vpa106cslzc_8cpp-source.html>.
[12] <http://maxdb-7.5.00.sourcearchive.com/documentation/7.5.00.44-2/vpa108csulzh_8cpp-source.html>.
[13] <http://radare.org/y/>.
[14] <https://service.sap.com/securitynotes>.
CoreLabs, the research center of Core Security, A Fortra Company is charged with researching and understanding security trends as well as anticipating the future requirements of information security technologies. CoreLabs studies cybersecurity trends, focusing on problem formalization, identification of vulnerabilities, novel solutions, and prototypes for new technologies. The team is comprised of seasoned researchers who regularly discover and discloses vulnerabilities, informing product owners in order to ensure a fix can be released efficiently, and that customers are informed as soon as possible. CoreLabs regularly publishes security advisories, technical papers, project information, and shared software tools for public use at <https://www.coresecurity.com/core-labs>.
Core Security, a Fortra Company, provides organizations with critical, actionable insight about who, how, and what is vulnerable in their IT environment. With our layered security approach and robust threat-aware, identity & access, network security, and vulnerability management solutions, security teams can efficiently manage security risks across the enterprise. Learn more at www.coresecurity.com.
Core Security is headquartered in the USA with offices and operations in South America, Europe, Middle East and Asia. To learn more, contact Core Security at (678) 304-4500 or [email protected].
The contents of this advisory are copyright Β© 2015 Core Security and Β© 2015 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: <http://creativecommons.org/licenses/by-nc-sa/3.0/us/>
This advisory has been signed with the GPG key of Core Security advisories team.