var-201607-0243
Vulnerability from variot
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++
-
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
-
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].
-
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.
-
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.
- Credits
This vulnerability was discovered and researched by Lucas Molas. The publication of this advisory was coordinated by Programa Seguridad en TIC.
- 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
'
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;
}
}
-----/
- 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++.
- 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
- 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
- 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
Show details on source website{
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/VARIoTentry#",
"affected_products": {
"@id": "https://www.variotdbs.pl/ref/affected_products"
},
"configurations": {
"@id": "https://www.variotdbs.pl/ref/configurations"
},
"credits": {
"@id": "https://www.variotdbs.pl/ref/credits"
},
"cvss": {
"@id": "https://www.variotdbs.pl/ref/cvss/"
},
"description": {
"@id": "https://www.variotdbs.pl/ref/description/"
},
"exploit_availability": {
"@id": "https://www.variotdbs.pl/ref/exploit_availability/"
},
"external_ids": {
"@id": "https://www.variotdbs.pl/ref/external_ids/"
},
"iot": {
"@id": "https://www.variotdbs.pl/ref/iot/"
},
"iot_taxonomy": {
"@id": "https://www.variotdbs.pl/ref/iot_taxonomy/"
},
"patch": {
"@id": "https://www.variotdbs.pl/ref/patch/"
},
"problemtype_data": {
"@id": "https://www.variotdbs.pl/ref/problemtype_data/"
},
"references": {
"@id": "https://www.variotdbs.pl/ref/references/"
},
"sources": {
"@id": "https://www.variotdbs.pl/ref/sources/"
},
"sources_release_date": {
"@id": "https://www.variotdbs.pl/ref/sources_release_date/"
},
"sources_update_date": {
"@id": "https://www.variotdbs.pl/ref/sources_update_date/"
},
"threat_type": {
"@id": "https://www.variotdbs.pl/ref/threat_type/"
},
"title": {
"@id": "https://www.variotdbs.pl/ref/title/"
},
"type": {
"@id": "https://www.variotdbs.pl/ref/type/"
}
},
"@id": "https://www.variotdbs.pl/vuln/VAR-201607-0243",
"affected_products": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/affected_products#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
},
"@id": "https://www.variotdbs.pl/ref/sources"
}
},
"data": [
{
"model": "asn1c",
"scope": "lte",
"trust": 1.0,
"vendor": "objective",
"version": "7.0.1"
},
{
"model": "asn1c",
"scope": "lte",
"trust": 0.8,
"vendor": "objective",
"version": "7.0.1.x created c or c++ source code"
},
{
"model": "asn1c",
"scope": "eq",
"trust": 0.6,
"vendor": "objective",
"version": "7.0.1"
},
{
"model": "communications performance intelligence center software",
"scope": "eq",
"trust": 0.3,
"vendor": "oracle",
"version": "10.2"
},
{
"model": "communications performance intelligence center software",
"scope": "eq",
"trust": 0.3,
"vendor": "oracle",
"version": "10.1.5.1"
},
{
"model": "systems asn1c",
"scope": "eq",
"trust": 0.3,
"vendor": "objective",
"version": "7.0.1.0"
},
{
"model": "nexus",
"scope": "eq",
"trust": 0.3,
"vendor": "google",
"version": "5x"
},
{
"model": "virtualized packet core systems",
"scope": "eq",
"trust": 0.3,
"vendor": "cisco",
"version": "20.0"
},
{
"model": "virtualized packet core systems",
"scope": "eq",
"trust": 0.3,
"vendor": "cisco",
"version": "19.0"
},
{
"model": "virtualized packet core systems",
"scope": "eq",
"trust": 0.3,
"vendor": "cisco",
"version": "18.0"
},
{
"model": "staros",
"scope": "eq",
"trust": 0.3,
"vendor": "cisco",
"version": "20.0"
},
{
"model": "staros",
"scope": "eq",
"trust": 0.3,
"vendor": "cisco",
"version": "19.0"
},
{
"model": "staros",
"scope": "eq",
"trust": 0.3,
"vendor": "cisco",
"version": "18.0"
},
{
"model": "staros",
"scope": "eq",
"trust": 0.3,
"vendor": "cisco",
"version": "17.0"
},
{
"model": "asr series",
"scope": "eq",
"trust": 0.3,
"vendor": "cisco",
"version": "50000"
},
{
"model": "systems asn1c",
"scope": "ne",
"trust": 0.3,
"vendor": "objective",
"version": "7.0.2"
}
],
"sources": [
{
"db": "BID",
"id": "91836"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-003788"
},
{
"db": "CNNVD",
"id": "CNNVD-201607-546"
},
{
"db": "NVD",
"id": "CVE-2016-5080"
}
]
},
"configurations": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/configurations#",
"children": {
"@container": "@list"
},
"cpe_match": {
"@container": "@list"
},
"data": {
"@container": "@list"
},
"nodes": {
"@container": "@list"
}
},
"data": [
{
"CVE_data_version": "4.0",
"nodes": [
{
"children": [],
"cpe_match": [
{
"cpe23Uri": "cpe:2.3:a:objective_systems:asn1c:*:*:*:*:*:*:*:*",
"cpe_name": [],
"versionEndIncluding": "7.0.1",
"vulnerable": true
}
],
"operator": "OR"
}
]
}
],
"sources": [
{
"db": "NVD",
"id": "CVE-2016-5080"
}
]
},
"credits": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/credits#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "Ivan Arce of Programa STIC at Fundaci\u00f3n Dr. Manuel Sadosky",
"sources": [
{
"db": "BID",
"id": "91836"
}
],
"trust": 0.3
},
"cve": "CVE-2016-5080",
"cvss": {
"@context": {
"cvssV2": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV2#"
},
"@id": "https://www.variotdbs.pl/ref/cvss/cvssV2"
},
"cvssV3": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV3#"
},
"@id": "https://www.variotdbs.pl/ref/cvss/cvssV3/"
},
"severity": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/cvss/severity#"
},
"@id": "https://www.variotdbs.pl/ref/cvss/severity"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
},
"@id": "https://www.variotdbs.pl/ref/sources"
}
},
"data": [
{
"cvssV2": [
{
"acInsufInfo": true,
"accessComplexity": "LOW",
"accessVector": "NETWORK",
"authentication": "NONE",
"author": "NVD",
"availabilityImpact": "COMPLETE",
"baseScore": 10.0,
"confidentialityImpact": "COMPLETE",
"exploitabilityScore": 10.0,
"impactScore": 10.0,
"integrityImpact": "COMPLETE",
"obtainAllPrivilege": false,
"obtainOtherPrivilege": false,
"obtainUserPrivilege": false,
"severity": "HIGH",
"trust": 1.0,
"userInteractionRequired": false,
"vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C",
"version": "2.0"
},
{
"acInsufInfo": null,
"accessComplexity": "Low",
"accessVector": "Network",
"authentication": "None",
"author": "NVD",
"availabilityImpact": "Complete",
"baseScore": 10.0,
"confidentialityImpact": "Complete",
"exploitabilityScore": null,
"id": "CVE-2016-5080",
"impactScore": null,
"integrityImpact": "Complete",
"obtainAllPrivilege": null,
"obtainOtherPrivilege": null,
"obtainUserPrivilege": null,
"severity": "High",
"trust": 0.9,
"userInteractionRequired": null,
"vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C",
"version": "2.0"
}
],
"cvssV3": [
{
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"author": "NVD",
"availabilityImpact": "HIGH",
"baseScore": 9.8,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"exploitabilityScore": 3.9,
"impactScore": 5.9,
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"trust": 1.0,
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.0"
},
{
"attackComplexity": "Low",
"attackVector": "Network",
"author": "NVD",
"availabilityImpact": "High",
"baseScore": 9.8,
"baseSeverity": "Critical",
"confidentialityImpact": "High",
"exploitabilityScore": null,
"id": "CVE-2016-5080",
"impactScore": null,
"integrityImpact": "High",
"privilegesRequired": "None",
"scope": "Unchanged",
"trust": 0.8,
"userInteraction": "None",
"vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.0"
}
],
"severity": [
{
"author": "NVD",
"id": "CVE-2016-5080",
"trust": 1.8,
"value": "CRITICAL"
},
{
"author": "CNNVD",
"id": "CNNVD-201607-546",
"trust": 0.6,
"value": "CRITICAL"
},
{
"author": "VULMON",
"id": "CVE-2016-5080",
"trust": 0.1,
"value": "HIGH"
}
]
}
],
"sources": [
{
"db": "VULMON",
"id": "CVE-2016-5080"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-003788"
},
{
"db": "CNNVD",
"id": "CNNVD-201607-546"
},
{
"db": "NVD",
"id": "CVE-2016-5080"
}
]
},
"description": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/description#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "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. \t\tFundaciA3n Dr. ASN1C compiler for C/C++\n\n\n1. ASN1C compiler for C/C++\nAdvisory ID: STIC-2016-0603\nAdvisory URL: http://www.fundacionsadosky.org.ar/publicaciones-2\nDate published: 2016-07-18\nDate of last update: 2016-07-19\nVendors contacted: Objective Systems Inc. \nRelease mode: Coordinated release\n\n\n2. *Vulnerability Description*\n\nAbstract Syntax Notation One (ASN.1) is a technical standard and formal\nnotation that describes rules and structures for representing, encoding,\ntransmitting, and decoding data in telecommunications and computer\nnetworking[1]. It is a joint standard of the International Organization\nfor Standardization (ISO), International Electrotechnical Commission\n(IEC), and International Telecommunication Union Telecommunication\nStandardization Sector ITU-T[2] used in technical standards for wireless\ncommunications such as GSM, UMTS and LTE, Lawful Interception,\nIntelligent Transportation Systems, signalling in fixed and mobile\ntelecommunications networks (SS7), wireless broadband access (WiMAX),\ndata security (X.509), network management (SNMP), voice over IP and\nIP-based videoconferencing (H.323), manufacturing, aviation, aerospace\nand several other areas[3]. \n\nSoftware components that generate, transmit and parse ASN.1 encoded data\nconstitute a critical building block of software that runs on billions\nof mobile devices, telecommunication switching equipment and systems for\noperation and management of critical infrastructures. The ASN.1\nspecification is sufficiently complicated to make writing programs that\nparse ASN.1 encoded data a perilious and error-prone activity. Many\ntechnology vendors have adopted the practice of using computer-generated\nprograms to parse ASN.1 encoded data. This is accomplished by using an\nASN.1 compiler, a software tool that given as input a data specification\nwritten in ASN.1 generates as output the source code of a program that\ncan be used to encode and decode in compliance with the specification. \nThe output of an ASN.1 compiler is generally incorporated as a building\nblock in a software system that transmits or processes ASN.1 encoded data. is a US-based private company[5] that develops\nand commercializes ASN1C, a ASN1 compiler for various programming\nlanguages, to vendors in the telecommunications, data networking,\naviation, aerospace, defense and law enforcement sectors[6]. \nThe vulnerability could be triggered remotely without any authentication\nin scenarios where the vulnerable code receives and processes ASN.1\nencoded data from untrusted sources, these may include communications\nbetween mobile devices and telecommunication network infrastructure\nnodes, communications between nodes in a carrier\u0027s network or across\ncarrier boundaries, or communication between mutually untrusted\nendpoints in a data network. has addressed the issue and built a fixed interim\nversion of the ASN1C for C/C++ compiler that is a available to customers\nupon request. The fixes will be incorporated in the next (v7.0.2)\nrelease of ASN1C for C/C++. \n\nFor further information about vulnerable vendors and available fixes\nrefer to the CERT/CC vulnerability note [4]. \n\n\n4. ASN1C compiler for C/C++ version 7.0 or below. Refer to the\nCERT/CC vulnerability note[4] for a list of potentially affected vendors. \n\n\n5. *Vendor Information, Solutions and Workarounds*\n\nVendor fixed the issue in an interim release of the ASN1C v7.0.1\ncompiler available to customers upon request[5]. The upcoming ASN1C\nv7.0.2 release will incorporate the fixes. \n\n\n6. *Credits*\n\nThis vulnerability was discovered and researched by Lucas Molas. The\npublication of this advisory was coordinated by Programa Seguridad en TIC. \n\n7. *Technical Description*\n\nThis document details a bug found in the latest release of Objective\nSystems Inc,. ASN1C compiler for C/C++ (v7.0.0), particularly in the\n\u0027rtxMemHeapAlloc\u0027 function contained in the pre-compiled \u0027asn1rt_a.lib\u0027\nlibrary, where two integer overflows have been detected, which could\nlead to corruption of heap memory in an attacker-controlled scenario. \n\nThe component analyzed was the \"evaluation package of ASN1C\" (v7.0.0)\nfor Windows (x86) MSVC 32-bit, but the analysis also applies to other\nplatforms. The analysis was performed with the IDA (v6.9) disassembler,\nfrom which the assembly blocks shown below have been extracted (the\nassembly syntax and location addresses may vary). \n\nThe pre-compiled library analyzed, \u0027asn1rt_a.lib\u0027, was extracted from\n\u0027\u003cinstalldir\u003e\\c\\lib\\\u0027 (which corresponds to the Visual C++ 2013 version). \n\n In \u0027rtxMemHeapAlloc\u0027, after initial checks to the context\u0027s internal\nmemory heap (\u0027pMemHeap\u0027) which may entail calls to \u0027rtxMemHeapCreate\u0027\nand \u0027rtxMemHeapCheck\u0027, the \u0027nbytes\u0027 argument (\u0027arg_4\u0027 in the\ndisassembly) is manipulated. Its value is rounded to the next multiple\nof 8 bytes using \u0027ecx\u0027 and storing the result in \u0027var_9C\u0027. To accomplish\nthis, a value of \u00277\u0027 is added to \u0027ecx\u0027 before making the shift without\nchecking the resulting value, which could lead to an integer overflow of\nthe 32-bit register if the value of \u0027nbytes\u0027 is \u00270xFFFFFFF9\u0027 or higher. \nThe following assembly blocks illustrate this. \n\n\n/-----\n loc_A6:\n mov ecx, [ebp+arg_4]\n add ecx, 7\n shr ecx, 3\n mov [ebp+var_9C], ecx\n mov edx, [ebp+var_18]\n mov eax, [edx+18h]\n and eax, 20000000h\n jnz short loc_D2\n\n\n-----/\n\nThe \u0027rtxMemHeapAlloc\u0027 function does not perform any validation of the\n\u0027nbytes\u0027 argument and therefore it is up to the caller to make sure its\nvalue does not overflow when the allocator rounds it up to a multiple of\n8 bytes and adds 20 bytes to the memory to be allocated to accomodate a\nheap control structure. However, the caller of \u0027rtxMemHeapAlloc\u0027 will be\na function automatically generated by the ASN1C compiler and typically\nwill not have any size contrains on the arguments passed to\n\u0027rtxMemHeapAlloc\u0027, and indireddctly to \u0027malloc\u0027, unless added manually. \nThe resulting value of \u0027var_9C\u0027 is checked against the constant \u00270FFFCh\u0027\nto decide whether to allocate the memory requested using the internal\nheap implementation or the system\u0027s memory allocator, which is usually\navailable through the \u0027malloc\u0027 function. \n\nA similar pattern is found later when \u0027malloc\u0027 is called. \n\nIf \u0027malloc\u0027 is used, the value in \u0027var_9C\u0027 is discarded in favor of the\noriginal value of the \u0027nbytes\u0027 argument. This value is added to \u002714h\u0027 in\n\u0027ecx\u0027 before saving it to \u0027var_E8\u0027 without any validation which could\nlead to an integer overflow if the value of argument \u0027nbytes\u0027 is\n\u00270xFFFFFFEC\u0027 or greater. The resulting value in \u0027var_E8\u0027 is then used as\nthe argument for the call to \u0027malloc\u0027. As a consequence, large values\npasssed in the \u0027nbytes\u0027 argument to \u0027rtxMemHeapAlloc\u0027 will result in a\nsize calculation that wraps around and ends up calling \u0027malloc\u0027 with a\nsize argument that is less that what is needed to store the data that\nwill be copied to it later on. The following assembly block illustrates\nthis. \n\n\n/-----\n loc_D2:\n mov ecx, [ebp+arg_4]\n add ecx, 14h\n mov [ebp+var_E8], ecx\n mov edx, [ebp+var_E8]\n push edx\n mov eax, [ebp+var_18]\n mov ecx, [eax+1Ch]\n call ecx\n add esp, 4\n mov [ebp+var_24], eax\n cmp [ebp+var_24], 0\n jnz short loc_120\n\n\n-----/\n\n\nDue to the fact that the bugs are located in the core runtime support\nlibrary, it is hard to assess its exploitability in all scenarios but it\nis safe to assume that it would lead attacker controlled memory\ncorruption of either the system\u0027s heap (if \u0027malloc\u0027 is called) or in the\ninternal memory allocator (if the number of bytes requested is below the\naforementioned threshold). Since heap control structures can be\noverwritten with attacker controlled data, it is safe to assume that\nremote code execution can be achieved in many scenarios in which ASN.1\nparsing code generated by the ASN1C compiler for C/C++ is used without\nmanual modification. Manual modification of automatically generated code\nis generally not recommended so mechanisms that would prevent triggering\nof these bugs are not likely to be found in deployed systems. \n\nAs an illustrative example, the 3GPP APIs can be mentioned, particularly\nthe \u0027[NAS/RRC add-on for ASN1C SDK]\u0027[7]. The C code generated by the\nASN1C for the RRC decoder (\u0027EUTRA-RRC-DefinitionsDec.c\u0027), uses\n\u0027rtxMemHeapAlloc\u0027 for the allocation of the extension optional bits of\nthe extension elements) where the length, not known in advance, is\nobtained from the encoded element received from an untrusted source,\ncalling \u0027pd_SmallLength\u0027 which allows unconstrained whole numbers,\nresulting in a call to \u0027rtxMemHeapAlloc\u0027 with an externally controlled\n\u0027nbytes\u0027 argument. \n\n\n/-----\n /* decode extension elements */\n if (extbit) {\n OSOCTET* poptbits;\n\n /* decode extension optional bits length */\n\n stat = pd_SmallLength (pctxt, \u0026bitcnt);\n if (stat != 0) return stat;\n\n poptbits = (OSOCTET*) rtxMemAlloc (pctxt, bitcnt);\n if (0 == poptbits) return RTERR_NOMEM;\n\n for (i_ = 0; i_ \u003c bitcnt; i_++) {\n stat = DEC_BIT (pctxt, \u0026poptbits[i_]);\n if (stat != 0) {\n rtxMemFreePtr (pctxt, poptbits);\n return stat;\n }\n }\n\n\n-----/\n\n\n8. *Report Timeline*\n\n. 2016-06-03:\n\n Sent email to Objective Systems Inc. 2016-06-06:\n\n Vendor responded with contact information to send the bug report\nin plaintext. 2016-06-06:\n\n Bug report sent in plaintext to the email address provided by\nthe vendor. The report included technical details to identify and\nreproduce the bug. Publication date set to July\n6, 2016. 2016-06-08:\n\n CERT/CC contacted, bug report filed in a web form, encrypted\nusing the CERT/CC PGP public key. 2016-06-08:\n\n CERT/CC replied by email acknowledging report, assigned VR-198\nas internal tracking number. 2016-06-08:\n\n Email sent to CERT/CC saying that the bug is present in code\ngenerated by the ASN1C compiler for C, it is also likely that C++ code\nis also buggy and not likely in Java code but neither C++ not Java code\nwere tested. 2016-06-10:\n\n Email sent to the vendor requesting acknowledgement of the\nreport sent on June 6 and noting that CERT/CC was contacted. 2016-06-10:\n\n Vendor acknowledged reception of the bug report and stated that\nit will look into the issue as time permits. indicated that the issues were fixed in\nan interim v7.0.1.x version of ASN1C that will be available to customers\nupon request and that the next v7.0.2 release will incorporate the\nfixes. Offered a version of ASN1C updated with the fixes for testing. 2016-06-14:\n\n Programa STIC replied to the vendor accepting the offer for the\npre-release version of ASN1C with the fixes and stated it is on track\nfor publication on July 6. 2016-06-15:\n\n Programa STIC notified CERT/CC that the vendor has fixed the\nissues and will make available an updated version of ASN1C to customers\nupon request. Asked CERT/CC about plans for dissemination of the report\nand whether it had contact information for ITU IMPACT. Publication is\nstill planned for July 6. 2016-06-16:\n\n CERT/CC replied saying they have no contact information for ITU\nIMPACT but will try to reach as many potentially affected vendors as\npossible. The vulnerabilities were assigned the CVE-2016-5080\nidentifier. CERT/CC will likely publish a Vulnerability Note on its\nwebsite once the report becomes public. 2016-06-16:\n\n Programa STIC said that vendors will need to assess whether\nthey\u0027re vulnerable and determine if they want to ask Objective Systems\nfor the fixed interim v7.0.1.x version or wait for the v7.0.2 release. \nPrograma STIC recommends the former since the v7.0.2 release may include\nnon-security fixed and feature and does not have a estimated release\ndate at the moment. 2016-06-27:\n\n Programa STIC sent mail to CERT/CC requesting a status update\nand saying its on track to publish on July 6. 2016-07-01:\n\n CERT/CC replied saying one of the contacted vendors requested to\ndelay the publication for 2 months while they investigate their\nproducts. Asked if Programa STIC would accept the request or proceed\nwith the current publication date. 2016-07-01:\n\n Programa STIC replied that a two month delay seemed excessive\nand that at least 2 additional factors should be weighed: 1. memory\ncorruption bugs in ASN.1 related components of an LTE stack have been\nannounced or hinted at in several infosec conference presentations over\nthe past few weeks and its likely the same or similar bugs will become\npublic soon. 2. Objective Systems has already produced a fix that is\navailable upon request to all its customers. It does not seem reasonable\nto impose a 2 month publication delay on every other vendor. Asked\nCERT/CC: 1. Did other vendors request to postpone publication or\nindicated they were or were not vulnerable? 2. Did CERT/CC disseminate\nthe information to any other parties?\n\n\n. 2016-07-01:\n\n CERT/CC indicated they\u0027ve contacted as many vendors as possible,\nUS-CERT and international CERT partners and that only one vendor has\nrequested to delay publication so far. Agreed that proceeding with the\noriginal publication schedule is reasonable given the partial disclosure\ndue to dissemination that already occurred plus the fact that a fix is\navailable\n\n\n. 2016-07-01:\n\n Programa STIC sent mail to CERT/CC saying that for the moment it\nwill proceed with the original deadline but make a final decision on July 5. 2016-07-06:\n\n Programa STIC sent email to CERT/CC indicating it decided to\npostpone publication for a week to give vendors some additional time to\nassess whether they are vulnerable and plan for issuing fixes. The new\npublication date was set to July 13. 2016-07-06:\n\n CERT/CC replied that it will notify vendors of the new\npublication date. 2016-07-14:\n\n Programa STIC told CERT/CC that publication was postponed to\nMonday, July 18. 2016-07-13:\n\n Programa STIC sent mail to Objective Systems Inc. asked if a CVE ID has been assigned to the\nissue. 2016-07-13:\n\n Programa STIC sent mail to Objective Systems Inc. saying\nCVE-2016-5080 was assigned by CERT and promising to send draft of the\nsecurity advisory when ready for publication. 2016-07-14:\n\n Programa STIC sent email to Objective Systems informing them that\nthe security advisory will bul published on July 18 with guidance for\npotentially affected vendors to contact them to request a fixed version\nof the ASN1C compiler for C/C++. \n\n\n9. *References*\n\n[1] Abstract Syntaxt Notation One (ASN1)\n http://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx\n[2] ASN.1 Project (ITU)\n http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx\n[3] ASN.1 Applications and Standards\n http://www.oss.com/asn1/resources/standards-use-asn1.html\n[4] CERT/CC Vulnerability Notes\n http://www.kb.cert.org/vuls\n[5] Objective Systems Inc. \n https://www.obj-sys.com\n[6] Vendors possibly using ASN.1 compiler for C/C++. \n https://www.obj-sys.com/customers/\n[7] Non-Access Stratum (NAS) LTE, GERAN-RRC, and other non-ASN.1 APIs\n 3GPP TS 24.007 24.008 24.011 24.301 44.018. \n https://www.obj-sys.com/products/asn1apis/lte_3gpp_apis.php\n\n10. *About FundaciA3n Dr. Manuel Sadosky*\n\nThe Dr. Manuel Sadosky Foundation is a mixed (public / private)\ninstitution whose goal is to promote stronger and closer interaction\nbetween industry and the scientific-technological system in all aspects\nrelated to Information and Communications Technology (ICT). The\nFoundation was formally created by a Presidential Decree in 2009. Its\nChairman is the Minister of Science, Technology, and Productive\nInnovation of Argentina; and the Vice-chairmen are the chairmen of the\ncountryas most important ICT chambers: The Software and Computer\nServices Chamber (CESSI) and the Argentine Computing and\nTelecommunications Chamber (CICOMRA). For more information visit:\nhttp://www.fundacionsadosky.org.ar\n\n11. *Copyright Notice*\n\nThe contents of this advisory are copyright (c) 2014-2016 FundaciA3n\nSadosky and are licensed under a Creative Commons Attribution\nNon-Commercial Share-Alike 4.0 License:\nhttp://creativecommons.org/licenses/by-nc-sa/4.0/\n-- \nPrograma de Seguridad en TIC\nFundaciA3n Dr. Manuel Sadosky\nAv. CA3rdoba 744 Piso 5 Oficina I\nTE/FAX: 4328-5164\n\n",
"sources": [
{
"db": "NVD",
"id": "CVE-2016-5080"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-003788"
},
{
"db": "BID",
"id": "91836"
},
{
"db": "VULMON",
"id": "CVE-2016-5080"
},
{
"db": "PACKETSTORM",
"id": "137970"
}
],
"trust": 2.07
},
"external_ids": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/external_ids#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"db": "NVD",
"id": "CVE-2016-5080",
"trust": 2.9
},
{
"db": "CERT/CC",
"id": "VU#790839",
"trust": 2.8
},
{
"db": "BID",
"id": "91836",
"trust": 1.4
},
{
"db": "PACKETSTORM",
"id": "137970",
"trust": 1.2
},
{
"db": "SECTRACK",
"id": "1036386",
"trust": 1.1
},
{
"db": "JVN",
"id": "JVNVU99625371",
"trust": 0.8
},
{
"db": "JVNDB",
"id": "JVNDB-2016-003788",
"trust": 0.8
},
{
"db": "CNNVD",
"id": "CNNVD-201607-546",
"trust": 0.6
},
{
"db": "VULMON",
"id": "CVE-2016-5080",
"trust": 0.1
}
],
"sources": [
{
"db": "VULMON",
"id": "CVE-2016-5080"
},
{
"db": "BID",
"id": "91836"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-003788"
},
{
"db": "PACKETSTORM",
"id": "137970"
},
{
"db": "CNNVD",
"id": "CNNVD-201607-546"
},
{
"db": "NVD",
"id": "CVE-2016-5080"
}
]
},
"id": "VAR-201607-0243",
"iot": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/iot#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": true,
"sources": [
{
"db": "VARIoT devices database",
"id": null
}
],
"trust": 0.51222601
},
"last_update_date": "2024-04-19T22:40:09.559000Z",
"patch": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/patch#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"title": "ASN1C ASN.1 Compiler",
"trust": 0.8,
"url": "http://www.obj-sys.com/products/asn1c/"
},
{
"title": "Objective Systems ASN1C for C/C++ Fixes for integer overflow vulnerabilities",
"trust": 0.6,
"url": "http://www.cnnvd.org.cn/web/xxk/bdxqbyid.tag?id=63003"
},
{
"title": "Android Security Bulletins: Android Security Bulletin\u2014January 2017",
"trust": 0.1,
"url": "https://vulmon.com/vendoradvisory?qidtp=android_security_bulletins\u0026qid=e8654f311f23268a7da69416ca7535a2"
},
{
"title": "Oracle: Oracle Critical Patch Update Advisory - October 2018",
"trust": 0.1,
"url": "https://vulmon.com/vendoradvisory?qidtp=oracle_advisories\u0026qid=81c63752a6f26433af2128b2e8c02385"
},
{
"title": "SamsungReleaseNotes",
"trust": 0.1,
"url": "https://github.com/samreleasenotes/samsungreleasenotes "
}
],
"sources": [
{
"db": "VULMON",
"id": "CVE-2016-5080"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-003788"
},
{
"db": "CNNVD",
"id": "CNNVD-201607-546"
}
]
},
"problemtype_data": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/problemtype_data#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"problemtype": "NVD-CWE-Other",
"trust": 1.0
},
{
"problemtype": "CWE-Other",
"trust": 0.8
}
],
"sources": [
{
"db": "JVNDB",
"id": "JVNDB-2016-003788"
},
{
"db": "NVD",
"id": "CVE-2016-5080"
}
]
},
"references": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/references#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"trust": 2.9,
"url": "http://www.kb.cert.org/vuls/id/790839"
},
{
"trust": 2.5,
"url": "https://github.com/programa-stic/security-advisories/tree/master/objsys/cve-2016-5080"
},
{
"trust": 2.5,
"url": "https://www.ncsc.nl/dienstverlening/response-op-dreigingen-en-incidenten/beveiligingsadviezen/ncsc-2016-0650+1.00+kwetsbaarheid+verholpen+in+asn1c.html"
},
{
"trust": 1.4,
"url": "http://tools.cisco.com/security/center/content/ciscosecurityadvisory/cisco-sa-20160721-asn1c"
},
{
"trust": 1.4,
"url": "http://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html"
},
{
"trust": 1.2,
"url": "http://www.securityfocus.com/bid/91836"
},
{
"trust": 1.1,
"url": "http://packetstormsecurity.com/files/137970/objective-systems-inc.-asn1c-for-c-c-heap-memory-corruption.html"
},
{
"trust": 1.1,
"url": "http://seclists.org/fulldisclosure/2016/jul/65"
},
{
"trust": 1.1,
"url": "http://www.securityfocus.com/archive/1/538952/100/0/threaded"
},
{
"trust": 1.1,
"url": "http://www.securitytracker.com/id/1036386"
},
{
"trust": 1.1,
"url": "https://source.android.com/security/bulletin/2017-01-01.html"
},
{
"trust": 0.8,
"url": "http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2016-5080"
},
{
"trust": 0.8,
"url": "http://jvn.jp/cert/jvnvu99625371"
},
{
"trust": 0.8,
"url": "http://web.nvd.nist.gov/view/vuln/detail?vulnid=cve-2016-5080"
},
{
"trust": 0.3,
"url": "http://www.obj-sys.com/"
},
{
"trust": 0.3,
"url": "https://source.android.com/security/bulletin/2017-01-01.html "
},
{
"trust": 0.3,
"url": "https://github.com/programa-stic/security-advisories/tree/master/objsys/cve-2016-5080/"
},
{
"trust": 0.1,
"url": "https://cwe.mitre.org/data/definitions/.html"
},
{
"trust": 0.1,
"url": "https://nvd.nist.gov"
},
{
"trust": 0.1,
"url": "https://www.obj-sys.com/customers/"
},
{
"trust": 0.1,
"url": "https://nvd.nist.gov/vuln/detail/cve-2016-5080"
},
{
"trust": 0.1,
"url": "http://www.itu.int/en/itu-t/asn1/pages/asn1_project.aspx"
},
{
"trust": 0.1,
"url": "https://www.obj-sys.com"
},
{
"trust": 0.1,
"url": "http://www.oss.com/asn1/resources/standards-use-asn1.html"
},
{
"trust": 0.1,
"url": "http://www.fundacionsadosky.org.ar"
},
{
"trust": 0.1,
"url": "http://www.itu.int/en/itu-t/asn1/pages/introduction.aspx"
},
{
"trust": 0.1,
"url": "https://www.obj-sys.com/products/asn1apis/lte_3gpp_apis.php"
},
{
"trust": 0.1,
"url": "http://creativecommons.org/licenses/by-nc-sa/4.0/"
},
{
"trust": 0.1,
"url": "http://www.kb.cert.org/vuls"
},
{
"trust": 0.1,
"url": "http://www.fundacionsadosky.org.ar/publicaciones-2"
}
],
"sources": [
{
"db": "VULMON",
"id": "CVE-2016-5080"
},
{
"db": "BID",
"id": "91836"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-003788"
},
{
"db": "PACKETSTORM",
"id": "137970"
},
{
"db": "CNNVD",
"id": "CNNVD-201607-546"
},
{
"db": "NVD",
"id": "CVE-2016-5080"
}
]
},
"sources": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#",
"data": {
"@container": "@list"
}
},
"data": [
{
"db": "VULMON",
"id": "CVE-2016-5080"
},
{
"db": "BID",
"id": "91836"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-003788"
},
{
"db": "PACKETSTORM",
"id": "137970"
},
{
"db": "CNNVD",
"id": "CNNVD-201607-546"
},
{
"db": "NVD",
"id": "CVE-2016-5080"
}
]
},
"sources_release_date": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources_release_date#",
"data": {
"@container": "@list"
}
},
"data": [
{
"date": "2016-07-19T00:00:00",
"db": "VULMON",
"id": "CVE-2016-5080"
},
{
"date": "2016-07-19T00:00:00",
"db": "BID",
"id": "91836"
},
{
"date": "2016-07-21T00:00:00",
"db": "JVNDB",
"id": "JVNDB-2016-003788"
},
{
"date": "2016-07-19T20:01:11",
"db": "PACKETSTORM",
"id": "137970"
},
{
"date": "2016-07-20T00:00:00",
"db": "CNNVD",
"id": "CNNVD-201607-546"
},
{
"date": "2016-07-19T22:59:01.240000",
"db": "NVD",
"id": "CVE-2016-5080"
}
]
},
"sources_update_date": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources_update_date#",
"data": {
"@container": "@list"
}
},
"data": [
{
"date": "2018-10-17T00:00:00",
"db": "VULMON",
"id": "CVE-2016-5080"
},
{
"date": "2018-10-17T07:00:00",
"db": "BID",
"id": "91836"
},
{
"date": "2016-07-21T00:00:00",
"db": "JVNDB",
"id": "JVNDB-2016-003788"
},
{
"date": "2016-07-20T00:00:00",
"db": "CNNVD",
"id": "CNNVD-201607-546"
},
{
"date": "2018-10-17T01:29:50.837000",
"db": "NVD",
"id": "CVE-2016-5080"
}
]
},
"threat_type": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/threat_type#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "remote",
"sources": [
{
"db": "CNNVD",
"id": "CNNVD-201607-546"
}
],
"trust": 0.6
},
"title": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/title#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "Objective Systems ASN1C Buffer overflow vulnerability in source code generated",
"sources": [
{
"db": "JVNDB",
"id": "JVNDB-2016-003788"
}
],
"trust": 0.8
},
"type": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/type#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "digital error",
"sources": [
{
"db": "CNNVD",
"id": "CNNVD-201607-546"
}
],
"trust": 0.6
}
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.