Find file History
Latest commit 0ee3be3 Jul 18, 2016 @ia-sadosky ia-sadosky many typos corrected
Failed to load latest commit information. many typos corrected Jul 19, 2016

Heap memory corruption in ASN.1 parsing code generated by Objective Systems Inc. ASN1C compiler for C/C++

1. Advisory Information

Title: Heap memory corruption in ASN.1 parsing code generated by Objective Systems Inc. ASN1C compiler for C/C++

Advisory ID: CVE-2016-5080

Advisory URL:

Date published: 2016-07-18

Date of last update: 2016-07-19

Vendors contacted: Objective Systems Inc.

Release mode: Coordinated release

2. Vulnerability Information

Class: Heap-based Buffer Overflow []

Impact: Code execution

Remotely Exploitable: Yes

Locally Exploitable: Yes

CVE Identifier:

3. 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.

Objective Systems Inc. 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].

A vulnerability found in the runtime support libraries of the ASN1C compiler for C/C++ from Objective Systems Inc. could allow an attacker to remotely execute code in software systems, including embeded software and firmware, that use code generated by the ASN1C compiler. 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.

Objective Systemns Inc. 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. Vulnerable packages

Software systems that use ASN.1 parsing code generated with Objective Systems Inc. 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 \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.

  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.

  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. The following ASN1C compiler generated C code snipped from the function asn1PD_RadioResourceConfigCommonSIB illustrates this.

   /* 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. requesting security contact information.

  • 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. Vendor is notified that CERT/CC will be contacted and that a security bulletin will be published. 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.

  • 2016-06-14: Objective Systems Inc. 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 ghd 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 customners 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: Objective Systems provided a fixed version of ASN1C for testing.

  • 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 rlease 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 excesive 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 availble

  • 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 adiditional 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 puublicaiton date.

  • 2016-07-13: CERT/CC asked if the security advisory was published and requested an URL for it.

  • 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. notifiying them that the security advisory will be published on July 18.

  • 2016-07-13: 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++.

  • 2016-07-18: Security advisory was published.

9. References

[1] Abstract Syntaxt Notation One (ASN1)

[2] ASN.1 Project (ITU)

[3] ASN.1 Applications and Standards

[4] CERT/CC Vulnerability Notes

[5] Objective Systems Inc.

[6] Vendors possibly using ASN.1 compiler for C/C++.

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

10. About Fundación 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 country’s most important ICT chambers: The Software and Computer Services Chamber (CESSI) and the Argentine Computing and Telecommunications Chamber (CICOMRA). For more information visit:

11. Copyright Notice

The contents of this advisory are copyright (c) 2014-2016 Fundación Sadosky and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 4.0 License: