[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[CORE-2015-0009] - SAP LZC/LZH Compression Multiple Vulnerabilities



1. Advisory Information

Title: SAP LZC/LZH Compression Multiple Vulnerabilities
Advisory ID: CORE-2015-0009
Advisory URL: 
http://www.coresecurity.com/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

2. Vulnerability Information

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


3. Vulnerability Description

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.


4. Vulnerable Packages

SAP Netweaver Application Server ABAP.
SAP Netweaver Application Server Java.
SAP Netweaver RFC SDK
SAP RFC SDK
SAP GUI
SAP MaxDB database
SAPCAR archive tool
Other products and versions might be affected, but they were not tested.


5. Vendor Information, Solutions and Workarounds

SAP published the following Security Notes:

2124806
2121661
2127995
2125316
They can be accessed by SAP clients in their Support Portal [15].

Developers who used the Open Source versions of MaxDB 7.5 and 7.6 for their 
tools should contact SAP.


6. Credits

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.



7. Technical Description / Proof of Concept Code

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][11].

The code that handles the decompression of LZC and LZH compressed data is prone 
to two memory corruption vulnerabilities, as described below.

7.1. LZC decompression stack-based buffer overflow

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 [12]]. 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).

7.2. LZH decompression out-of-bounds read

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 [13]]. 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.

7.3. Attack scenarios

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:

7.3.1. Attacks against server-side components

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.

7.3.2. Client-side attacks

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.

7.3.3. Man-in-the-middle attacks

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.

7.4. Looking in binaries for compression routines

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 [14] 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       ..............  
 


8. Report Timeline

2015-01-20: Core Security sends an initial notification to SAP. Publication 
date set to Mar 10, 2015 (Patch Tuesday).
2015-01-21: SAP confirms reception and requests a draft version of the advisory.
2015-01-21: Core Security sends the draft version of the advisory to the vendor.
2015-01-21: SAP confirms reception of the report and assigns the following 
security message Number: 55318 2015.
2015-01-22: SAP asks if the two vulnerable functions mentioned in the draft are 
the only ones affected by these vulnerabilities.
2015-01-22: Core Security informs the vendor that researchers were only able to 
trigger the vulnerabilities in the functions mentioned in the draft advisory. 
In case they find other instances where the vulnerabilities can be triggered, 
Core requests to be informed.
2015-01-30: Core Security asks the vendor if they were able to verify the 
vulnerabilities in order to coordinate a proper release date.
2015-02-02: SAP states that they verified and confirmed the vulnerabilities, 
are working on a solution, and will provide an update once the solution plan is 
finished.
2015-02-04: SAP states that they will be able to provide a fix by May's Patch 
Tuesday, 2015, and not March as requested. They also request to know how the 
advisory is going to be published and if we have any plans to include them in 
any upcoming presentations.
2015-02-10: SAP requests confirmation of their previous email in order to 
coordinate the advisory for the May 12th, 2015.
2015-02-18: Core Security informs SAP that the date is confirmed and that 
researchers might present something after the publication of the advisory.
2015-02-19: SAP states that it is thankful for Core's commitment to go for a 
coordinated release. They say they will keep us updated.
2015-05-07: Core Security reminds SAP that the date for the proposed fix to be 
released is the following week, therefore we would like to resume 
communications in order to publish our findings in a coordinated manner.
2015-05-07: SAP informs that they are on track to release the security notes as 
part of their May patch day (May 12th, 2015).
2015-05-11: Core Security asks SAP for the specific time they are planning to 
publish their security note and requests a tentative link so it can be included 
in Core's advisory. Additionally, Core sends a tentative fix for the source 
code that it is planning to add in its advisory for SAP to review, and a list 
of vulnerable tools that used the vulnerable code so SAP can contact and inform 
the owners of the fix.
2015-05-12: SAP states that they published 4 security notes regarding the 
issues we reported. They requested for us to wait 3 months to publish our 
findings and to send them the advisory before is published.
2015-05-12: Core Security requests that SAP fixes the external ID (Core's ID) 
they used and offer Core's publication link. Additionally, Core explained that 
is their policy to release their findings the same day the vendor does. Core 
also reminded SAP that they were still waiting for a reply to their previous 
email.
2015-05-12: Advisory CORE-2015-0009 published.


9. References

[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] http://blog.ptsecurity.com/2011/10/sap-diag-decompress-plugin-for.html. 
[7] https://github.com/CoreSecurity/pysap. 
[8] https://github.com/CoreSecurity/SAP-Dissection-plug-in-for-Wireshark. 
[9] https://github.com/daberlin/sap-reposrc-decompressor. 
[10] https://labs.mwrinfosecurity.com/tools/sap-decom/. 
[11] http://www.oxid.it/cain.html. 
[12] 
http://maxdb-7.5.00.sourcearchive.com/documentation/7.5.00.44-2/vpa106cslzc_8cpp-source.html.
 
[13] 
http://maxdb-7.5.00.sourcearchive.com/documentation/7.5.00.44-2/vpa108csulzh_8cpp-source.html.
 
[14] http://radare.org/y/. 
[15] https://service.sap.com/securitynotes. 


10. About CoreLabs

CoreLabs, the research center of Core Security, is charged with anticipating 
the future needs and requirements for information security technologies. We 
conduct our research in several important areas of computer security including 
system vulnerabilities, cyber attack planning and simulation, source code 
auditing, and cryptography. Our results include problem formalization, 
identification of vulnerabilities, novel solutions and prototypes for new 
technologies. CoreLabs regularly publishes security advisories, technical 
papers, project information and shared software tools for public use at: 
http://corelabs.coresecurity.com.


11. About Core Security

Core Security enables organizations to get ahead of threats with security test 
and measurement solutions that continuously identify and demonstrate real-world 
exposures to their most critical assets. Our customers can gain real visibility 
into their security standing, real validation of their security controls, and 
real metrics to more effectively secure their organizations.

Core Security's software solutions build on over a decade of trusted research 
and leading-edge threat expertise from the company's Security Consulting 
Services, CoreLabs and Engineering groups. Core Security can be reached at +1 
(617) 399-6980 or on the Web at: http://www.coresecurity.com.


12. Disclaimer

The contents of this advisory are copyright (c) 2015 Core Security and (c) 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/


13. PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security advisories 
team, which is available for download at 
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.