ID

VAR-201607-0243

CVE

CVE-2016-5080

TITLE

Objective Systems ASN1C generates code that contains a heap overflow vulnerability

DESCRIPTION

Integer overflow in the rtxMemHeapAlloc function in asn1rt_a.lib in Objective Systems ASN1C for C/C++ before 7.0.2 allows context-dependent attackers to execute arbitrary code or cause a denial of service (heap-based buffer overflow), on a system running an application compiled by ASN1C, via crafted ASN.1 data. ASN.1 Is a standard data structure notation for network and communication applications. Heap-based buffer overflow (CWE-122) - CVE-2016-5080 ASN1C Is ASN.1 Used to generate high-level language source code from the syntax. According to the reporter, ASN1C Generated by C Or C++ The source code of the heap manager rtxMemHeapAlloc A heap-based buffer overflow vulnerability exists in the function. 2016 Year 7 Moon 20 As of today, similar vulnerabilities Java And C# It is unknown whether it exists in the source code output by. rtxMemHeapAlloc It depends on whether you are using a function. Specifically, it was received from an unreliable communication partner ASN.1 Processing your data may be affected by this vulnerability. For development of in-house products ASN1C Developers using are required to verify the source code to see if their products contain this vulnerability. The reporter has published further information as a security advisory. In the most serious case, received from an unreliable partner ASN.1 By processing the data, the authority of the application by a remote third party (root Or SYSTEM Authority etc. ) May execute arbitrary code. Failed exploit attempts will likely result in denial-of-service conditions. FundaciA3n Dr. ASN1C compiler for C/C++ 1. ASN1C compiler for C/C++ Advisory ID: STIC-2016-0603 Advisory URL: http://www.fundacionsadosky.org.ar/publicaciones-2 Date published: 2016-07-18 Date of last update: 2016-07-19 Vendors contacted: Objective Systems Inc. Release mode: Coordinated release 2. *Vulnerability Description* Abstract Syntax Notation One (ASN.1) is a technical standard and formal notation that describes rules and structures for representing, encoding, transmitting, and decoding data in telecommunications and computer networking[1]. It is a joint standard of the International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), and International Telecommunication Union Telecommunication Standardization Sector ITU-T[2] used in technical standards for wireless communications such as GSM, UMTS and LTE, Lawful Interception, Intelligent Transportation Systems, signalling in fixed and mobile telecommunications networks (SS7), wireless broadband access (WiMAX), data security (X.509), network management (SNMP), voice over IP and IP-based videoconferencing (H.323), manufacturing, aviation, aerospace and several other areas[3]. Software components that generate, transmit and parse ASN.1 encoded data constitute a critical building block of software that runs on billions of mobile devices, telecommunication switching equipment and systems for operation and management of critical infrastructures. The ASN.1 specification is sufficiently complicated to make writing programs that parse ASN.1 encoded data a perilious and error-prone activity. Many technology vendors have adopted the practice of using computer-generated programs to parse ASN.1 encoded data. This is accomplished by using an ASN.1 compiler, a software tool that given as input a data specification written in ASN.1 generates as output the source code of a program that can be used to encode and decode in compliance with the specification. The output of an ASN.1 compiler is generally incorporated as a building block in a software system that transmits or processes ASN.1 encoded data. is a US-based private company[5] that develops and commercializes ASN1C, a ASN1 compiler for various programming languages, to vendors in the telecommunications, data networking, aviation, aerospace, defense and law enforcement sectors[6]. The vulnerability could be triggered remotely without any authentication in scenarios where the vulnerable code receives and processes ASN.1 encoded data from untrusted sources, these may include communications between mobile devices and telecommunication network infrastructure nodes, communications between nodes in a carrier's network or across carrier boundaries, or communication between mutually untrusted endpoints in a data network. has addressed the issue and built a fixed interim version of the ASN1C for C/C++ compiler that is a available to customers upon request. The fixes will be incorporated in the next (v7.0.2) release of ASN1C for C/C++. For further information about vulnerable vendors and available fixes refer to the CERT/CC vulnerability note [4]. 4. ASN1C compiler for C/C++ version 7.0 or below. Refer to the CERT/CC vulnerability note[4] for a list of potentially affected vendors. 5. *Vendor Information, Solutions and Workarounds* Vendor fixed the issue in an interim release of the ASN1C v7.0.1 compiler available to customers upon request[5]. The upcoming ASN1C v7.0.2 release will incorporate the fixes. 6. *Credits* This vulnerability was discovered and researched by Lucas Molas. The publication of this advisory was coordinated by Programa Seguridad en TIC. 7. *Technical Description* This document details a bug found in the latest release of Objective Systems Inc,. ASN1C compiler for C/C++ (v7.0.0), particularly in the 'rtxMemHeapAlloc' function contained in the pre-compiled 'asn1rt_a.lib' library, where two integer overflows have been detected, which could lead to corruption of heap memory in an attacker-controlled scenario. The component analyzed was the "evaluation package of ASN1C" (v7.0.0) for Windows (x86) MSVC 32-bit, but the analysis also applies to other platforms. The analysis was performed with the IDA (v6.9) disassembler, from which the assembly blocks shown below have been extracted (the assembly syntax and location addresses may vary). The pre-compiled library analyzed, 'asn1rt_a.lib', was extracted from '<installdir>\c\lib\' (which corresponds to the Visual C++ 2013 version). In 'rtxMemHeapAlloc', after initial checks to the context's internal memory heap ('pMemHeap') which may entail calls to 'rtxMemHeapCreate' and 'rtxMemHeapCheck', the 'nbytes' argument ('arg_4' in the disassembly) is manipulated. Its value is rounded to the next multiple of 8 bytes using 'ecx' and storing the result in 'var_9C'. To accomplish this, a value of '7' is added to 'ecx' before making the shift without checking the resulting value, which could lead to an integer overflow of the 32-bit register if the value of 'nbytes' is '0xFFFFFFF9' or higher. The following assembly blocks illustrate this. /----- loc_A6: mov ecx, [ebp+arg_4] add ecx, 7 shr ecx, 3 mov [ebp+var_9C], ecx mov edx, [ebp+var_18] mov eax, [edx+18h] and eax, 20000000h jnz short loc_D2 -----/ The 'rtxMemHeapAlloc' function does not perform any validation of the 'nbytes' argument and therefore it is up to the caller to make sure its value does not overflow when the allocator rounds it up to a multiple of 8 bytes and adds 20 bytes to the memory to be allocated to accomodate a heap control structure. However, the caller of 'rtxMemHeapAlloc' will be a function automatically generated by the ASN1C compiler and typically will not have any size contrains on the arguments passed to 'rtxMemHeapAlloc', and indireddctly to 'malloc', unless added manually. The resulting value of 'var_9C' is checked against the constant '0FFFCh' to decide whether to allocate the memory requested using the internal heap implementation or the system's memory allocator, which is usually available through the 'malloc' function. A similar pattern is found later when 'malloc' is called. If 'malloc' is used, the value in 'var_9C' is discarded in favor of the original value of the 'nbytes' argument. This value is added to '14h' in 'ecx' before saving it to 'var_E8' without any validation which could lead to an integer overflow if the value of argument 'nbytes' is '0xFFFFFFEC' or greater. The resulting value in 'var_E8' is then used as the argument for the call to 'malloc'. As a consequence, large values passsed in the 'nbytes' argument to 'rtxMemHeapAlloc' will result in a size calculation that wraps around and ends up calling 'malloc' with a size argument that is less that what is needed to store the data that will be copied to it later on. The following assembly block illustrates this. /----- loc_D2: mov ecx, [ebp+arg_4] add ecx, 14h mov [ebp+var_E8], ecx mov edx, [ebp+var_E8] push edx mov eax, [ebp+var_18] mov ecx, [eax+1Ch] call ecx add esp, 4 mov [ebp+var_24], eax cmp [ebp+var_24], 0 jnz short loc_120 -----/ Due to the fact that the bugs are located in the core runtime support library, it is hard to assess its exploitability in all scenarios but it is safe to assume that it would lead attacker controlled memory corruption of either the system's heap (if 'malloc' is called) or in the internal memory allocator (if the number of bytes requested is below the aforementioned threshold). Since heap control structures can be overwritten with attacker controlled data, it is safe to assume that remote code execution can be achieved in many scenarios in which ASN.1 parsing code generated by the ASN1C compiler for C/C++ is used without manual modification. Manual modification of automatically generated code is generally not recommended so mechanisms that would prevent triggering of these bugs are not likely to be found in deployed systems. As an illustrative example, the 3GPP APIs can be mentioned, particularly the '[NAS/RRC add-on for ASN1C SDK]'[7]. The C code generated by the ASN1C for the RRC decoder ('EUTRA-RRC-DefinitionsDec.c'), uses 'rtxMemHeapAlloc' for the allocation of the extension optional bits of the extension elements) where the length, not known in advance, is obtained from the encoded element received from an untrusted source, calling 'pd_SmallLength' which allows unconstrained whole numbers, resulting in a call to 'rtxMemHeapAlloc' with an externally controlled 'nbytes' argument. /----- /* decode extension elements */ if (extbit) { OSOCTET* poptbits; /* decode extension optional bits length */ stat = pd_SmallLength (pctxt, &bitcnt); if (stat != 0) return stat; poptbits = (OSOCTET*) rtxMemAlloc (pctxt, bitcnt); if (0 == poptbits) return RTERR_NOMEM; for (i_ = 0; i_ < bitcnt; i_++) { stat = DEC_BIT (pctxt, &poptbits[i_]); if (stat != 0) { rtxMemFreePtr (pctxt, poptbits); return stat; } } -----/ 8. *Report Timeline* . 2016-06-03: Sent email to Objective Systems Inc. 2016-06-06: Vendor responded with contact information to send the bug report in plaintext. 2016-06-06: Bug report sent in plaintext to the email address provided by the vendor. The report included technical details to identify and reproduce the bug. Publication date set to July 6, 2016. 2016-06-08: CERT/CC contacted, bug report filed in a web form, encrypted using the CERT/CC PGP public key. 2016-06-08: CERT/CC replied by email acknowledging report, assigned VR-198 as internal tracking number. 2016-06-08: Email sent to CERT/CC saying that the bug is present in code generated by the ASN1C compiler for C, it is also likely that C++ code is also buggy and not likely in Java code but neither C++ not Java code were tested. 2016-06-10: Email sent to the vendor requesting acknowledgement of the report sent on June 6 and noting that CERT/CC was contacted. 2016-06-10: Vendor acknowledged reception of the bug report and stated that it will look into the issue as time permits. indicated that the issues were fixed in an interim v7.0.1.x version of ASN1C that will be available to customers upon request and that the next v7.0.2 release will incorporate the fixes. Offered a version of ASN1C updated with the fixes for testing. 2016-06-14: Programa STIC replied to the vendor accepting the offer for the pre-release version of ASN1C with the fixes and stated it is on track for publication on July 6. 2016-06-15: Programa STIC notified CERT/CC that the vendor has fixed the issues and will make available an updated version of ASN1C to customers upon request. Asked CERT/CC about plans for dissemination of the report and whether it had contact information for ITU IMPACT. Publication is still planned for July 6. 2016-06-16: CERT/CC replied saying they have no contact information for ITU IMPACT but will try to reach as many potentially affected vendors as possible. The vulnerabilities were assigned the CVE-2016-5080 identifier. CERT/CC will likely publish a Vulnerability Note on its website once the report becomes public. 2016-06-16: Programa STIC said that vendors will need to assess whether they're vulnerable and determine if they want to ask Objective Systems for the fixed interim v7.0.1.x version or wait for the v7.0.2 release. Programa STIC recommends the former since the v7.0.2 release may include non-security fixed and feature and does not have a estimated release date at the moment. 2016-06-27: Programa STIC sent mail to CERT/CC requesting a status update and saying its on track to publish on July 6. 2016-07-01: CERT/CC replied saying one of the contacted vendors requested to delay the publication for 2 months while they investigate their products. Asked if Programa STIC would accept the request or proceed with the current publication date. 2016-07-01: Programa STIC replied that a two month delay seemed excessive and that at least 2 additional factors should be weighed: 1. memory corruption bugs in ASN.1 related components of an LTE stack have been announced or hinted at in several infosec conference presentations over the past few weeks and its likely the same or similar bugs will become public soon. 2. Objective Systems has already produced a fix that is available upon request to all its customers. It does not seem reasonable to impose a 2 month publication delay on every other vendor. Asked CERT/CC: 1. Did other vendors request to postpone publication or indicated they were or were not vulnerable? 2. Did CERT/CC disseminate the information to any other parties? . 2016-07-01: CERT/CC indicated they've contacted as many vendors as possible, US-CERT and international CERT partners and that only one vendor has requested to delay publication so far. Agreed that proceeding with the original publication schedule is reasonable given the partial disclosure due to dissemination that already occurred plus the fact that a fix is available . 2016-07-01: Programa STIC sent mail to CERT/CC saying that for the moment it will proceed with the original deadline but make a final decision on July 5. 2016-07-06: Programa STIC sent email to CERT/CC indicating it decided to postpone publication for a week to give vendors some additional time to assess whether they are vulnerable and plan for issuing fixes. The new publication date was set to July 13. 2016-07-06: CERT/CC replied that it will notify vendors of the new publication date. 2016-07-14: Programa STIC told CERT/CC that publication was postponed to Monday, July 18. 2016-07-13: Programa STIC sent mail to Objective Systems Inc. asked if a CVE ID has been assigned to the issue. 2016-07-13: Programa STIC sent mail to Objective Systems Inc. saying CVE-2016-5080 was assigned by CERT and promising to send draft of the security advisory when ready for publication. 2016-07-14: Programa STIC sent email to Objective Systems informing them that the security advisory will bul published on July 18 with guidance for potentially affected vendors to contact them to request a fixed version of the ASN1C compiler for C/C++. 9. *References* [1] Abstract Syntaxt Notation One (ASN1) http://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx [2] ASN.1 Project (ITU) http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx [3] ASN.1 Applications and Standards http://www.oss.com/asn1/resources/standards-use-asn1.html [4] CERT/CC Vulnerability Notes http://www.kb.cert.org/vuls [5] Objective Systems Inc. https://www.obj-sys.com [6] Vendors possibly using ASN.1 compiler for C/C++. https://www.obj-sys.com/customers/ [7] Non-Access Stratum (NAS) LTE, GERAN-RRC, and other non-ASN.1 APIs 3GPP TS 24.007 24.008 24.011 24.301 44.018. https://www.obj-sys.com/products/asn1apis/lte_3gpp_apis.php 10. *About FundaciA3n Dr. Manuel Sadosky* The Dr. Manuel Sadosky Foundation is a mixed (public / private) institution whose goal is to promote stronger and closer interaction between industry and the scientific-technological system in all aspects related to Information and Communications Technology (ICT). The Foundation was formally created by a Presidential Decree in 2009. Its Chairman is the Minister of Science, Technology, and Productive Innovation of Argentina; and the Vice-chairmen are the chairmen of the countryas most important ICT chambers: The Software and Computer Services Chamber (CESSI) and the Argentine Computing and Telecommunications Chamber (CICOMRA). For more information visit: http://www.fundacionsadosky.org.ar 11. *Copyright Notice* The contents of this advisory are copyright (c) 2014-2016 FundaciA3n Sadosky and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 4.0 License: http://creativecommons.org/licenses/by-nc-sa/4.0/ -- Programa de Seguridad en TIC FundaciA3n Dr. Manuel Sadosky Av. CA3rdoba 744 Piso 5 Oficina I TE/FAX: 4328-5164

AFFECTED PRODUCTS

CVSS

PROBLEMTYPE DATA

THREAT TYPE

remote

TYPE

digital error

CONFIGURATIONS

PATCH

EXTERNAL IDS

REFERENCES

CREDITS

Ivan Arce of Programa STIC at Fundación Dr. Manuel Sadosky

SOURCES

LAST UPDATE DATE

2024-11-23T23:05:35.467000+00:00

SOURCES UPDATE DATE

SOURCES RELEASE DATE