​安全公告：ASN.1编码中存在堆内存崩溃漏洞

1.安全公告信息

标题：Objective系统集成有限公司所设计的ASN.1编码规范中存在一个可以引发堆内存崩溃的安全漏洞。

漏洞CVE编号：CVE-2016-5080

公告URL地址：http://www.fundacionsadosky.org.ar/publicaciones-2

漏洞公布日期：2016-07-18

公告最新更新时间：2016-07-19

相关供应厂商：Objective系统集成公司

漏洞披露模式：协同披露

2.漏洞信息

漏洞分类：基于堆内存的缓冲区溢出[http://cwe.mitre.org/data/definitions/122.html]

漏洞影响：代码执行

是否远程可利用：是

是否本地可利用：是

漏洞标识：http://cve.mitre.org/cgi-bin/cvename.cgi?name=2016-5080

3.漏洞描述

ASN.1抽象语法标记是一种 ISO/ITU-T 标准，它描述了一种对计算机网络数据进行表示、编码、传输和解码的数据格式规范。

它提供了一整套用于描述对象结构的格式标准，开发人员无需关心编程语言具体如何执行这些命令，而且也不用了解这些数据的具体指代在任何需要以数字方式发送信息的地方，ASN.1 都可以发送各种形式的信息（声频、视频、数据等等）。

ASN.1 和特定的 ASN.1 编码规则推进了结构化数据的传输，尤其是网络中不同应用程序之间的结构化数据传输，它以一种独立于计算机架构和语言的方式来描述数据结构。

OSI 协议中的应用层协议使用了 ASN.1 来描述它们所传输的 PDU，这些协议包括：用于传输电子邮件的 X.400，用于目录服务的 X.500，以及用于 VoIP 的 H.323 和 SNMP。它的应用还可以扩展到通用移动通信系统（UMTS）中的接入和非接入层。

ASN.1 取得成功的一个主要原因是它与几个标准化编码规则相关，如基本编码规则（BER） -X.209 、规范编码规则（CER）、识别名编码规则（DER）、压缩编码规则（PER）和 XML编码规则（XER）。这些编码规则描述了如何对 ASN.1 中定义的数值进行编码，以便用于传输，而无需关心计算机、编程语言或它在应用程序中如何表示等因素。

ASN.1 的编码方法比许多与之竞争的标记系统更为先进，它支持可扩展信息快速可靠的传输 — 在无线宽带中，这是一种优势。1984年，ASN.1 就已经成为了一种国际标准，它的编码规则已经十分成熟了，并在可靠性和兼容性方面拥有更加丰富的处理经验。ASN.1是描述在网络上传输信息格式的标准方法。它主要由两个部分组成：一部分用于描述信息内部的数据，数据类型，以及序列格式；另一部分用于描述如何将各部分数据组成消息。它原来是作为X.409的一部分而开发的，后来才自己独立成为一个标准。

ASN.1 的描述可以容易地被映射成 C 或 C++ 或 Java 的数据结构，它可以被应用程序代码使用，并得到运行时程序库的支持，进而能够编码和解码 XML或TLV 格式的数据。

除此之外，ASN.1也是一种用于描述结构化客体的结构和内容的语言。ASN.1 C++编译器是ASN.1 C编译器的增强版本, 它采用了面向对象编程技术。ASN.1 C++编译器可以自动将ASN.1规范编译为C++类和用来编解码的元数据。此外，C++运行时库的ASN.1也是ASN.1 C++编译器软件包的一部分。ASN.1 C++运行库同时也是面向元数据的，元数据可以在运行时载入，并且可以在使用后释放。

Objective集成系统有限公司是美国的一家私营企业，ASN1C编译器正是由这家公司开发设计的。目前，在电信，数据网络，航空航天，国防部门，以及政府执法部门等多个领域的企业或组织都在使用这一编译器。

这个存在于ASN1C编译器运行时支持库中的漏洞将会允许攻击者在目标软件系统中远程执行代码，受影响的系统还包括使用了ASN1C编译器的嵌入式软件系统在内。根据安全研究专家的分析，当目标系统中的漏洞代码从不受信任的来源处接收并处理ASN.1编码数据时，攻击者就可以在不经过任何身份验证的情况下远程触发这一漏洞。在移动设备和通信运营商的网络基础设施节点之间的通信，以及运营商网络节点之间的通信过程中，都将有可能出现这样的安全问题。

据了解，Objective集成系统有限公司目前已经成功解决了这个问题，并且为了满足客户的需求，公司还发布了一个临时版本的ASN1C C/C++编译器。根据公司透露的信息，他们将会在下一版本(v7.0.2)的ASN1C编译器中正式修复这一漏洞。

如果大家想要了解更多关于受影响厂商和漏洞缓解方案的信息，请访问CERT/CC发布的漏洞公告。

4.受漏洞影响的系统

任何使用了ASN.1编码规范的软件系统都将会受到这一漏洞的影响。除此之外，7.0版本及7.0版本以下的ASN1C编译器也将会受到该漏洞的影响。CERT/CC漏洞公告中提供了一个受此漏洞影响的厂商名单，感兴趣的读者可以点击查看。

5.厂商信息和解决方案

为了满足客户的要求，厂商已经发布了一个临时版本的ASN1C(v7.0.1)以供用户使用。公司将会在ASN1C v7.0.2正式版本中修复这一漏洞。

6.漏洞发现者

这个漏洞是由安全研究专家Lucas Molas发现并报告的。

7.技术细节

在这一部分，我们将详细描述Objective集成系统有限公司所发布的最新版本ASN1C编译器(v7.0.0)中存在的这个安全漏洞。安全研究专家发现，在编译器的rtxMemHeapAlloc函数中包含有一个预编译的asn1rt_a.lib库，并在其中检测到了两个整数溢出问题，这个问题将有可能允许攻击者在目标系统中引发堆内存崩溃。

安全研究专家使用了IDA(v6.9)来对程序进行了反编译，并提取出了相应的代码块来进行进一步的分析。在对这个预编译的代码库进行了分析之后，研究人员便从clib路径下提取出了asn1rt_a.lib。

在对rtxMemHeapAlloc函数的分析过程中，研究人员首先对程序的堆内存(pMemHeap)进行了初步分析，rtxMemHeapCreate函数和rtxMemHeapCheck函数会在堆内存空间中被调用，nbytes参数（反编译结果为arg_4）会被修改。程序会利用ecx寄存器来将参数值填充至八个字节大小（或者八字节的整数倍），并将结果存储至变量var_9C之中。为了实现这一步操作，在对结果值进行移位操作之前，ecx的值会加7。在32位寄存器中，如果没有对结果值进行检测，那么当nbytes的值为0xFFFFFFF9或者更大时，则将有可能引起整数溢出问题。具体代码如下所示：

 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

rtxMemHeapAlloc函数并不会对nbytes参数进行任何验证，因此，程序就只能指望参数的调用者来对其进行检测，以确保它的值不会溢出。但是，rtxMemHeapAlloc函数的调用者是一个由ASN1C编译器自动生成的函数，通常这类函数在默认情况下并不会对传递的参数进行任何限制，除非我们手动对其进行 设置。

如果malloc函数被调用，var_9C变量中的值将会被丢弃，取而代之的是nbytes参数的初始值。在这个值被保存至变量var_E8中之前，会在ecx寄存器中加上14h。

此时，代码并不会对这个值进行检测，如果参数nbytes的值为0xFFFFFFEC或者更大的话，将有可能引起整数溢出问题。具体代码如下：

  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

由于该漏洞存在于核心运行支持库中，所以安全研究专家很难去评估该漏洞的利用情况。

但是根据分析之后的结果显示，攻击者可以利用这个漏洞来引发系统堆内存崩溃，或者是引起内存空间的分配问题。

由于篇幅有限，如果读者还想了解更多有关这一漏洞的详细信息，请点击查看原文。