Superbugs: 10 software bugs that took way too long to meet their maker
By Phil Johnson, IT World, 13 November 2014.
By Phil Johnson, IT World, 13 November 2014.
All software has bugs, but even the most well known applications can have errors and vulnerabilities that somehow go undetected for years.
Earlier this week, Microsoft patched a security vulnerability that, it turns out, has been present in every version of its operating systems since the release of Windows 1995, more than 19 years ago. As the IBM researchers who discovered the bug put it, it’s been “sitting in plain sight” while other vulnerabilities in the same library have been fixed over the years.
While it may seem surprising that a critical error in such a major piece of software, used by so many people, could go unnoticed for decades, it’s actually not that uncommon. For a variety of reasons, bugs can go undetected, or sometimes simply be ignored, for quite a long time in even the most widely used and critical pieces of code. Here we present 10 examples of software bugs that were particularly long-lived - not all of which have yet been fixed.
1. 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 was until 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.
2. 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.
3. 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.
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 non-existent leap day, the epoch was set to the non-existent 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 behaviour 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.
4. 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 centred 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.
5. 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.
6. 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 of this year, 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 just this week, more than 19 years after the problematic code was first released.
7. 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.
8. Windows’ NT Virtual DOS Machine problem
Image courtesy flickr/Sam Howzit
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 year, 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.
9. OpenSSL’s ChangeCipherSpec injection vulnerability
Image courtesy flickr/thefuturistics
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.
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 over 15 years before the problem was fixed.
10. IE6’s Flash exploit
Image courtesy flickr/Joe Goldberg
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.
Thirteen years after its release, IE6 only accounts for a meagre 1.68% 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.
No comments:
Post a Comment
Please adhere to proper blog etiquette when posting your comments. This blog owner will exercise his absolution discretion in allowing or rejecting any comments that are deemed seditious, defamatory, libelous, racist, vulgar, insulting, and other remarks that exhibit similar characteristics. If you insist on using anonymous comments, please write your name or other IDs at the end of your message.