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.

That was all well and good until the spring of 2015, when a security researcher at CrowdStrike discovered a VM escape vulnerability in QEMU’s virtual floppy disk controller (and, yes, developers still occasionally need access to virtual FDCs). The vulnerability, dubbed VENOM (for Virtualized Environment Neglected Operations Manipulation), could, in theory, allow those with bad intents to use the FDC code, which could still be accessed even if the virtual FDC is disabled, to cause a buffer overflow. The buffer overflow could allow a user to “escape” the VM and potentially have access to other VMs on the same server or even gain access to other servers on the host machine’s network. Fortunately, there’s no evidence that the bug has ever been exploited and CrowdStrike worked with many vendors to develop and issue patches in May 2015, before announcing the find, 11 years after the bug was introduced.

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% 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.

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% 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.

Windows’ 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, they 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.

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 over 25 years, until the first patches were released in September, 2014.

Excel’s year 1900 problem

Age: 27 years (and counting)

Date introduced: November, 1987

Date fixed: N/A

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. In order 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.

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.