Superbugs: 11 software bugs that took way too long to squash

All software has bugs, but even the most well known applications can have errors and vulnerabilities that somehow go undetected for years -- or decades.

By Phil Johnson , ITworld

Earlier this week a bug in a widely used piece of virtualization software was patched after it had sat unnoticed for 11 years. While it may seem surprising that a coding error in a commonly used piece of software could go unnoticed for years, it’s actually not that uncommon. For a variety of reasons, bugs can go undetected, or sometimes simply ignored, for quite a long time in even the most widely used and critical pieces of code. Use the arrows above to see 11 examples of software bugs that were particularly long-lived -- not all of which have yet been fixed.

Age: 37 years, 2 months

Date introduced: August, 1977

Date fixed: October, 2014

OpenBSD has only been around for 18 years, but until was recently susceptible to a bug that was actually created well before it was born. In August 1977, future Sun Microsystems co-founder Bill Joy wrote the head function, used to display the first lines of a file, for 1BSD, the initial release of the Berkeley Software Distribution (BSD), a Unix derivative. Joy’s original code was later inherited by forks and sub-forks of BSD, such as 386BSD, NetBSD, and OpenBSD.

15 years after Joy wrote head, in 1992, it was discovered that, under certain circumstances, it could raise an error, due to the use of a function called freopen to open files and streams for reading, which didn’t play nicely with stdin. Keith Bostic applied to the fix to 4.4BSD, but the bug remained in some BSD-derivatives, such as NetBSD, which was based on 386BSD in 1993, itself forked from 4.3BSD in 1989, which didn’t have Bostic’s fix. Subsequently, the bug was present when OpenBSD was created from NetBSD in 1996. In October 2014, Ingo Schwarze finally rectified the 18 year-old problem by merging Bostic’s 22 year-old fix into OpenBSD, a mere 37 years after the Joy wrote the original code.

IE6's Flash exploit

Age: 12 years, 9 months
Date introduced: August, 2001
Date fixed: May, 2014
Not long after Microsoft released version 6 of Internet Explorer (the last stand alone version) in August 2001 it became, by far, the dominant web browser in use, grabbing more than 90 percent of the market. Being the browser that just everybody used at the time made it, naturally, a popular target for hackers. However, particularly poor design, such as, for example, the fact that it runs with the same security level as the user, also made it especially vulnerable to exploits and earned it a place on many “worst software ever” lists.
Thirteen years after its release, IE6 only accounts for a meager 1.68 percent of the browser market, but serious security vulnerabilities are still being found. In April, 2014 security firm FireEye found a Flash exploitation in IE6, as well as all subsequent versions, that could allow remote code execution, giving hackers the same rights to the affected computer as the user. Despite the small market share still claimed by IE6, 7 and 8, in May Microsoft took the unusual step of issuing a security patch to fix the exploit all the way back to IE6 on Windows XP -- even though it stopped supporting XP just weeks earlier. While that almost 13 year-old IE6 bug has been fixed, other vulnerabilities still remain unpatched.

OpenSSL's ChangeCipherSpec injection vulnerability

Age: 15 years, 6 months
Date introduced: December 1998
Date fixed: June 2014
OpenSSL was created in 1998 as an open source implementation of the SSL and TSL protocols. It’s since become enormously popular and is currently the default encryption engine for Apache and nginx Web servers, which power 66 percent of all active web sites in the world. OpenSSL’s importance has helped garner it support from, among others, the U.S. Department of Homeland Security and Department of Defense.
In 2014, OpenSSL made headlines for being susceptible to the Heartbleed bug. In the wake of that serious vulnerability, other problems with the code were found, including one by Japanese researcher Masachi Kikuchi in June. Kikuchi discovered a problem with OpenSSL’s ChangeCipherSpec processing, which could allow hackers to instigate a man-in-the-middle attack by sending invalid signals during the handshake between client and server. While this vulnerability wasn’t nearly as bad as Heartbleed, it had existed for much longer, within all client versions of OpenSSL going back to its initial release, meaning it was more than 15 years before the problem was fixed.

Windows's NT Virtual DOS Machine problem

Age: 16 years, 8 months
Date introduced: July 1993
Date fixed: March, 2010
When Microsoft released its first 32-bit system, Windows NT in July 1993, it didn’t want to orphan all of the 16-bit software that was out there, not to mention good old DOS. Their solution was the Windows NT Virtual DOS Machine (VDM) which allowed such software to run on 32-bit NT computers. Using NT VDM, Windows NT users (and, in subsequent years, users of all 32-bit versions of Windows NT, 2000, XP, Server 2003, Vista, Server 2009 and Windows 7) could access DOS and 16-bit programs and all was good.
Fast forward about 16 years, when Google researcher Tavis Ormandy discovered a serious bug in the NT VDM code. As Ormandy was able to demonstrate, the vulnerability could allow a hacker logged directly into an affected computer (it couldn’t be exploited remotely) to elevate his or her privileges to System level. Ormandy reported to the bug to Microsoft in June 2009 and they released a security update fixing the issue -- but not, for some reason, until March 2010.

LZO's integer overflow condition

Age: 18 years, 3 months
Date introduced: March 1996
Date fixed: June 2014
In March 1996, Markus Oberhumer released a lossless data compression algorithm that was optimized for speed, known as Lempel–Ziv–Oberhumer (LZO). Since then, LZO and its variants have been incorporated into a wide variety of open source and proprietary software, including FFmpeg, the Linux Kernel, and Hadoop. LZO has even been used far from Earth, currently as part of the Mars Curiosity rover.
Almost two decades after its initial release, in 2014, Don Bailey of Lab Mouse Security found that Oberhumer’s original LZO algorithm was susceptible to integer overflows. The overflows could be triggered under fairly unusual, but not unheard of, conditions (specifically, when trying to decompress more than 16MB of compressed bytes on 32-bit systems). In theory, affected systems could be susceptible to remote code execution, denial of service attacks, and adjacent object overwrite. LZO version 2.07, which fixed the bug, was released in June, 2014. While it’s not known whether NASA has patched the code on Curiosity, it would be extremely difficult for an attacker to get a malicious payload to the rover, anyway.

Microsoft's Automation drive-by vulnerability

Age: 19 years, 3 months
Date introduced: August 1995
Date fixed: November 2014
With the release of Windows 95 in 1995, Microsoft made it easier for applications to communicate with each other and share disparate kinds of data through its Object Linking and Embedding (OLE) framework and Component Object Model (COM). One service built on COM that was included with Windows 95 was OLE Automation (now known simply as Automation) which was meant to be used by scripting languages for inter-process communication. Automation has been integral part of all Windows releases (including Server) since Win 95.
All was well until May, 2014 when IBM’s X-Force research team discovered a critical security hole in the OleAut32 library. The IBM team discovered that, starting with the release of Internet Explorer 3.0, which introduced VBScript, the complex and rare vulnerability could allow for drive-by attacks that could let hackers remotely take control of a computer. IBM shared their findings with Microsoft, who kept news of the problem quiet until a patch could be released, which finally happened more than 19 years after the problematic code was first released.

BSD's seekdir issue

Age: 24 years, 9 months
Date introduced: August 1983
Date fixed: May 2008
In the early days of BSD, the Berkeley Software Distribution variant of Unix, programs that needed to open and read files in a directory would do it directly. Starting with 4.2BSD in August 1983, however, the dir library was implemented, written by Kirk McKusick, who helped to take over development of BSD when Bill Joy, one of its creators, left to help found Sun Microsystems. McKusick’s code for iterating through directory files -- including a bug he didn’t catch -- remained a part of subsequent versions of BSD, as well the many forks of it, including, NetBSD, OpenBSD, and Mac OS X for years.
The bug came to light in 2008 when an OpenBSD developer named Marc Balmer set out to track down the reason that Samba was crashing when serving files from an MS-DOS system. The Samba code, it turned out, had a comment indicating that BSD had a problem with directory handling. After further digging, Balmer indeed discovered a bug in McKusick’s original seekdir routine (used to find the next entry in a directory stream) that occurred when iterating through a directory in which files have been deleted. The fix turned out to be far simpler than the work required to track it down.

Bash's Shellshock vulnerability

Age: 25 years, 1 month
Date introduced: August 1989
Date fixed: September 2014
In 1989, Brian Fox created the Bash shell as part of the Gnu project. It was meant to be a replacement for the existing Bourne shell (hence the acronym which stands for “Bourne-again shell”). It was successful in its quest, becoming an integral part of all Unix-based systems over the years, from BSD to Linux to Mac OS X, and the default shell for many. Unbeknownst to Fox and everyone else, however, it also contained a very severe security vulnerability that would remain unnoticed for decades.
In 2014, Linux developer Stéphane Chazelas discovered what would become the first in a series of vulnerabilities that would be known as Shellshock. The exploit is centered around the fact that Bash would execute code included after function declarations in environment variables. Web servers were considered the most at risk, since Apache runs Bash in the background; malicious code could be sent via HTTP or CGI scripts. A variety of bad things could result, including hackers taking remote control of a server and the creation of botnets. It was determined that the Shellshock vulnerability was introduced in version 1.03 of Bash in August, 1989, where it remained exploitable for more than 25 years, until the first patches were released in September 2014.

Excel's year 1900 problem

Age: 27 years (and counting)
Date introduced: November 19867
Date fixed: Still open
When Microsoft was creating the first version of Excel for Windows in the mid-1980s, it was taking on the dominant PC spreadsheet of the time, IBM’s Lotus 1-2-3. To win over Lotus users, Microsoft wanted to make porting spreadsheets from Lotus as easy as possible. That meant copying a known Lotus bug into Excel: namely, that it treated 1900 as a leap year.
To make date calculations easier, Lotus 1-2-3 engineers knowingly ignored the fact that 1900 was not a leap year. To adjust for the nonexistent leap day, the epoch was set to the nonexistent January 0, 1900, meaning that any date from January 1 through February 28, 1900, was incorrectly represented, which was considered a minor problem. Microsoft copied this behavior into Excel for Windows starting with the first release in November 1987 (this bug doesn’t exist in Excel for Mac, which used January 1, 1904, as its epoch). The bug continues to live on, due to the numerous problems implementing a fix would create, 27 years later.

YACC's buffer overflow issue

Age: 33 years, 2 months
Date introduced: May 1975
Date fixed: July 2008
In 1975, Stephen Johnson working at AT&T Bell Labs, developed Yet Another Compiler-Compiler (YACC), a tool for generating the parser portion of a language compiler. Johnson’s YACC, first written in the B programming language then in C, was the default parser-generator on Unix systems for years. It was first included with the Sixth Edition of Unix, released by Bell Labs in May 1975 and Johnson’s YACC code was passed down to many later Unix derivatives, such as the BSD branch of the Unix tree.
In 2008, Otto Moerbeek, an OpenBSD developer, was trying to track down the reason that compiling some large C++ programs on Sparc64 systems would fail with an Internal Compiler Error. It turned out that a new memory allocation routine that he had written wasn’t the cause; instead, Johnson’s YACC code was to blame. Moerbeek’s new malloc code was able to detect that Johnson’s YACC would cause a buffer overflow under certain conditions on Sparc64 systems only. He fixed the problem in OpenBSD a little over 33 years after Johnson’s YACC code was first released.

OpenBSD's head bug

Age: 37 years, 2 months

Date introduced: August, 1977

Date fixed: October, 2014

OpenBSD has only been around for 18 years, but until was recently susceptible to a bug that was actually created well before it was born. In August 1977, future Sun Microsystems co-founder Bill Joy wrote the head function, used to display the first lines of a file, for 1BSD, the initial release of the Berkeley Software Distribution (BSD), a Unix derivative. Joy’s original code was later inherited by forks and sub-forks of BSD, such as 386BSD, NetBSD, and OpenBSD.

15 years after Joy wrote head, in 1992, it was discovered that, under certain circumstances, it could raise an error, due to the use of a function called freopen to open files and streams for reading, which didn’t play nicely with stdin. Keith Bostic applied to the fix to 4.4BSD, but the bug remained in some BSD-derivatives, such as NetBSD, which was based on 386BSD in 1993, itself forked from 4.3BSD in 1989, which didn’t have Bostic’s fix. Subsequently, the bug was present when OpenBSD was created from NetBSD in 1996. In October 2014, Ingo Schwarze finally rectified the 18 year-old problem by merging Bostic’s 22 year-old fix into OpenBSD, a mere 37 years after the Joy wrote the original code.