Home / os / palm

Objective Systems Inc. ASN1C For C/C++ Heap Memory Corruption

Posted on 30 November -0001

<HTML><HEAD><TITLE>Objective Systems Inc. ASN1C For C/C++ Heap Memory Corruption</TITLE><META http-equiv="Content-Type" content="text/html; charset=utf-8"></HEAD><BODY>FundaciA3n Dr. Manuel Sadosky - Programa STIC Advisory
      www.fundacionsadosky.org.ar

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: 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 Information*

Class: Heap-based Buffer Overflow [CWE-122]
Impact: Code execution
Remotely Exploitable: Yes
Locally Exploitable: Yes
CVE Identifier: CVE-2016-5080


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 embedded
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 Systems 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
'<installdir>clib' (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. 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 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:

         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 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-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. notifying 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)
    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</BODY></HTML>

 

TOP

Malware :

Exploits :