Abstract Syntax Notation One (ASN.1) is an almost invisible, underpinning technology of modern communication. It’s a method that hasn’t caught much attention outside of a certain tech niche. That may well change soon, since a problem with an ASN.1 compiler can cause a network vulnerability.

ASN.1 Explained

To truly appreciate the problem, we must start at the beginning. ASN.1 is a standard that defines a formalism for the specification of abstract data types. It was evolved as a project by 150-year-old telecommunications company International Telegraph Union (ITU).

According to the ITU, ASN.1 “sends information in any form (audio, video, data, etc.) anywhere it needs to be communicated digitally.” Since it “only covers the structural aspects of information,” ASN.1 is not considered a programming language. Rather, it’s a container to store data, no matter the form of that information.

ASN.1 has shown its usefulness with several standardized encoding rules, such as the Basic Encoding Rules (BER). The Packed Encoding Rules (PER) also work well under ASN.1. PER is very useful for applications that undergo bandwidth restrictions. Both of these describe how the values defined in ASN.1 should be encoded for transmission — that is, how they can be translated into the bytes over the wire and vice versa, regardless of the type of machine or underlying programming language.

According to ASN Lab, “an ASN.1 definition can be readily mapped (by a pre-runtime processor) into a C or C++ or Java data structure that can be used by application code and supported by runtime libraries providing encoding and decoding of representations in either an XML or a TLV format, or a very compact packed encoding format.”

It’s a slick way to eliminate coding problems in a very error-prone niche of programming — when it works, of course.

A Golden Standard?

ASN.1 is a joint standard of the International Organization for Standardization (ISO), International Electrotechnical Commission (IEC) and International Telecommunication Union Telecommunication Standardization Sector (ITU-T).

Further, ASN.1 is used in communications such as the Global System for Mobile Communication (GSM), Universal Mobile Telecommunications Service (UMTS) and Long-Term Evolution (LTE). It is also applied to lawful interception, intelligent transportation systems, signaling in fixed and mobile telecommunications networks, wireless broadband access, data security, network management, Voice-over-IP (VoIP) and IP-based videoconferencing, all across industries such as manufacturing, aviation, aerospace and several others.

As an older, proven standard, ASN.1 is widely adopted in the telecommunications industry. What could go wrong with such a golden standard? Hold on, we’re getting there.

ASN1C Flaw Leads to Network Vulnerability

Objective Systems, Inc. produced an ASN1C compiler that makes it compatible with a number of programming languages. Version 6.6, along with its runtime libraries, was released in 2013 to Objective’s customers, which span major government agencies and top conglomerates. The ASN1C compiler is used all over the place, even three years removed from the last update.

No one thought much about it, except for researchers from the Programa STIC at the Fundación Sadosky in Argentina. The researchers, according to GitHub, found an issue in ASN1C that can cause the code generated to become vulnerable to a heap overflow. This is a serious flaw that could allow attackers to remotely execute unknown and unauthorized code inside the firmware of devices that use the compiled ASN1C code from within C and C++.

Cisco fell on its sword first, becoming a victim of an ASN.1 problem. And the IT company had to admit that while patches might be released in the future, it wasn’t prepared to handle the onslaught. However, Cisco stated that the “Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability.

The kind of attack that would use this particular vulnerability is hard to mount. It requires very specific, sophisticated knowledge of the target device and its ability to insert communications freely into the channel. It would need to address individual devices in a way that ASN.1 was specifically designed to get around. Data in ASN.1 networks flow through hardware without the hardware affecting it. An attacker would need to know about all the devices traversed. In terms of its dependence upon hardware, this kind of attack is the conceptual opposite of ASN.1.

Dodging the Bullet

It seems that Qualcomm’s cellular products dodged this particular bullet altogether by establishing boundary checks. According to PC World, “the vulnerable ASN1C code was present in Qualcomm’s cellular stack, but was not exploitable because of a separate ASN.1 data encoding rule.”

A Qualcomm representative told PC World that to exploit the vulnerability an attacker must “send a large value in a specially crafted network signaling message, but the encoding rule specified in the 3G/4G standards and in our products does not allow such a large value to get through.”

Objective Systems also addressed the issue with a fixed interim version (v7.01) of the ASN1C for C/C++ compiler and runtimes. This version is available to customers “upon request.” The fixes will be incorporated in the next release (v7.0.2) of ASN1C for C/C++.

Cleanup Effort

ASN.1 isn’t boring anymore. While Objective Systems burned the midnight oil to fix the issue, the usual problem of disseminating the fixed code remains. Users must be proactive.

IT professionals may want to query all vendors to determine whether their software is affected by this vulnerability. Some, like Cisco, will tell the truth. Others may have secondary dependencies to consider. For example, they may be using vulnerable software purchased from another source in whatever solutions they deliver.

Even with the new compiler, a lot of vulnerable code is already out there. Make no mistake: The cleanup is going to be tough. The use of ASN.1 is so widespread, it’s unlikely to end here. New types of attacks may follow, but, for the moment, boundary limits seem to have defused the threat.