The facts behind Microsoft’s ASN.1 security vulnerability
Recently, Microsoft announced yet another security vulnerability. Yes, I know that Microsoft announces new security vulnerabilities every week, but this one requires your immediate attention. It’s a critical vulnerability that allows remote code execution on quite a few different Microsoft operating systems. I will explain the component affected by this vulnerability and show you how to keep your system safe.
The reason why the security hole affects so many different systems is because the bug exists within an ASN.1 library. ASN (Abstract Syntax Notation) is a set of data standards and devices. ASN.1, on the other hand, is a programming language used for defining various standards with no regard for how those standards will be implemented.
To get an idea of how ASN.1 works, think of the C programming language. You can write C code all day long, but not one line of that code is executable until the code is compiled. In order to compile the code, you need a compiler. There is no one standard C compiler. Instead, there are compilers for different platforms. For example, there are X86 compilers that compile C code to run on Intel processors. There are also Macintosh compilers that compile C code to run on Macintosh machines. The C code will remain the same regardless of which platform uses it. It’s up to the compiler to translate that code into something that a specific computer type understands.
ASN.1 works exactly the same way. Like C, ASN.1 is a high-level programming language that also has lots of different libraries that can be referenced. ASN.1 code is used to develop various commonly used standards. The ASN.1 code is then compiled and implemented as a part of various operating systems.
Common ASN.1 standards
Even if you have never heard of ASN.1, you are no doubt familiar with some of the standards that are written in ASN.1. These standards include X.400 (an electronic messaging standard implemented in Microsoft Exchange), X.500 (a Directory Services standard used by Active Directory), X.200 (a network communications standard), Light Weight Directory Access Protocol (LDAP, the protocol used for Active Directory Access), and many others.
My point is that ASN.1 is heavily used by Microsoft operating systems. Unfortunately, the recently discovered security vulnerability exists within the Microsoft ASN.1 libraries. This means that any code based on certain ASN.1 libraries is affected by the bug, making it very widespread.
Unchecked buffer vulnerability
Like so many other Microsoft security vulnerabilities, this particular security problem involves an unchecked buffer. An unchecked buffer implies the problem code does not take steps to monitor the contents of a buffer. If too much data is crammed into the buffer, the buffer will overflow and in doing so will expose the data that was previously contained within the buffer.
Hackers could then examine this data and use it to gain full administrative access to a system. Using this access, they could install applications, view, modify, or delete data. An attacker could even create a brand new account with full administrative privileges.
Under normal conditions, the chances of this particular buffer overflowing on its own are pretty slim. However, if a hacker knows the specific details of the buffer, they could easily write a small program whose sole purpose is to flood it, causing the dreaded buffer overflow.
Now that you know how the security vulnerability works, you are probably wondering which Microsoft products are vulnerable and what you can do about the problem. In the sections below, I will address each product individually.
If you are still running Microsoft Windows NT 4.0, you are in a unique situation. None of the versions of Windows NT 4.0 install the affected code by default. Ironically, the affected code is installed into Windows NT as a part of a hot fix (MS03-041). If you haven’t installed this particular update, then you may not be affected by this problem. However, it is possible that other hot fixes might have installed the problem code. The only way to tell for sure is to search your system’s hard drive for a file named MSASN1.DLL. If this file exists, then you will need the update. The actual update that you apply will differ depending on the version of Windows NT 4.0 you are running. Here is a list of the various versions of Windows NT 4.0 and the locations of their respective updates:
* Windows NT Workstation 4.0 Service Pack 6A
* Windows NT Server 4.0 Service Pack 6A
* Windows NT Server 4.0 Terminal Server Edition Service Pack 6
As with Windows NT, a default implementation of Windows 2000 Server or Windows 2000 Professional does not contain the security vulnerability. Instead, the vulnerability was introduced into these operating systems through service packs. Any machine running Windows 2000 Server or Windows 2000 Professional with Service Pack numbers two, three, or four are affected. Microsoft does intend to correct this issue in Service Pack five. In the mean time however, it is necessary to download and apply a fix. You can get the necessary fix from the Microsoft Download Center.
Windows XP is affected by the problem whether a service pack is installed or not. Both the Home and Professional versions are affected, as are the 32-bit and the 64-bit versions. If you are running the 64-bit version of Windows XP, then be sure to check out the section below on Windows Server 2003, because 64-bit versions of Windows XP use the same fix as the 64-bit version of Windows Server 2003.
Microsoft plans to include a fix for this vulnerability in Windows XP Service Pack two. In the meantime you should implement a patch to remove the vulnerability. Users of the 32-bit version of Windows XP can get the patch from the Microsoft Download Center. If you are running the 64-bit edition of Windows XP with Service Pack one, you can also get the necessary update from the Download Center. The same goes for users of the 64-bit version of Windows XP version 2003 with Service Pack one.
Windows Server 2003
As luck would have it, Windows Server 2003, the newest and supposedly most secure version of Windows in existence is also affected by this vulnerability. Because Windows Server 2003 is so new, there are currently no service packs to worry about, but Microsoft has committed to including a fix for this vulnerability in Service Pack one. In the meantime, you will want to apply a fix to get rid of the vulnerability. As with Windows XP, the fix that you will apply depends on whether you are using the 32-bit version or the 64-bit version.
Still not sure?
If you are still in doubt as to whether or not you need a fix and which fix you need, then I recommend downloading the Microsoft Baseline Security Advisor. This utility will analyze your system and tell you exactly what security patches are required.
Comments are closed.