11 old software bugs that took way too long to squash

As these examples show, vulnerabilities can lurk within production code for years or decades—and attacks can come at any time.

1 2 Page 2
Page 2 of 2

PuTTY is a free and open source suite of tools including a serial console, a terminal emulator, and various network file transfer applications, with SSH and various other encryption schemes built in. It was originally released to bring the sorts of tools that Unix administrators took for granted to Windows and classic Mac OS, but has expanded its scope and is now in wide use on Unix systems as well. While PuTTY was designed to secure network connections, it turns out there was a vulnerability lurking at its heart. This was another form of buffer overflow problem (a heap overflow, in this case), and could be triggered by a too-short SSH key, which could result in crashing PuTTY or even remote code execution.

The vulnerability was submitted to HackerOne as part of the bug bounty program established by the European Union's ; it netted the submitter a $3,645 reward and a thank you from the PuTTY team, who noted that the bug had been present in the very earliest versions of the PuTTY source code they had, dating back to 1999.

win32k.sys vulnerabilities

Age: 23 years
Date introduced: 1996
Date fixed: 2019

Two big vulnerabilities were detected in the Win32 API in Microsoft Windows in 2019. The first, found in April, was a User-After-Free vulnerability, in which OS coding errors made it possible for programs to access system memory that should've been protected; this vulnerability was detected by security researchers when they discovered malicious hackers attempting to use it in the wild to gain control of computers. The other, discovered in December, was an elevation-of-privilege vulnerability lurking in the OS's window switching functionality; this vulnerability was similarly discovered in the course of active attacks, which were simulating keystrokes in an attempt to create memory leaks.

Both vulnerabilities have their origins in the early days of Windows. "The problem originates from the time when WIN32K made its debut with Windows NT 4.0, when much of Win32's graphics engine was moved from user level to kernel to boost performance," explains Boris Larin, senior security researcher at Kaspersky. And while these two specific vulnerabilities have been patched, that long-ago decision on the part of Microsoft has had much broader effects—and probably will continue to do so, Larin says. "Throughout the years, the WIN32K component has been responsible for more than a half of all kernel security vulnerabilities discovered in Windows."


Age: 24 years
Date introduced: 1996
Date fixed: May 2020

Printers are a frequent pain point for IT because there are a lot of different kinds, they aren't made by the same vendors who make computers and operating systems, and users expect to plug them in and just start printing. Microsoft in particular in its early years battled to make installing a printer driver relatively easy and painless. But a recent bug, dubbed PrintDemon, showed that maybe they took that a bit too far back in the '90s—and are still paying for it today.

The core of the vulnerability lies in three facts: Non-administrative users can add printers to a Windows machine; the underlying mechanics make it possible to print to a file rather than a physical printing device; and crucial printing services on Windows run with SYSTEM privileges. That means that, if you do to it right, you can build a "printer" driver that can create a file (even an executable one) anywhere on the filesystem (even in privileged directories). There are plenty of exploits that have been cooked up over the years to take advantage of these design flaws—Stuxnet, it turns out, was one of them—but PrintDemon, discovered in 2020, was a real doozy, and was made possible because Microsoft's fixes over the years had been patches rather than a complete rebuild of the printing subsystem. As Winsider describes it, "With very subtle file system modifications, you can achieve file copy/write behavior that is not attributable to any process, especially after a reboot ... with a carefully crafted port name, you can imagine simply having the Spooler drop a [portable executable] file anywhere on disk for you." Sounds like bad news!

Why it matters

These lists are fun to come up with—it always elicits a thrill to realize that your computer might be hacked due to a vulnerability in the printer subsystem from the Clinton years—but there's a real-world importance to knowing about old bugs that goes beyond the immediate need to fix them. Adam Nichols, Principal at Grimm, says, "One of the things we do when we find a vulnerability in our independent research efforts is attempt to determine how long it has been present. This is unfortunately not the industry standard, but other researchers do sometimes do this as well. Going the extra mile to find out how long people were vulnerable is extra work, but I feel it's an important part of the conversation."

Nichols points to the research of Sandy Clark, who's shown that extensive code reuse has resulted in a large attack surface of known vulnerabilities, and that a codebase in long active use may eventually have its lurking vulnerabilities turned into exploits. This flies in the face of traditional software engineering dogma, which believes that most flaws will be fixed in the early days of a codebase's use as it encounters real-world problems and attacks. But it turns out that, in the words of Clark's paper's title, familiarity can breed contempt.  

Copyright © 2022 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
7 hot cybersecurity trends (and 2 going cold)