In 2021, a vulnerability was revealed in a system that lay at the foundation of modern computing. An attacker could force the system to execute arbitrary code. Shockingly, the vulnerable code was almost 54 years old—and there was no patch available, and no expectation that one would be forthcoming.
Fortunately, that’s because the system in question was Marvin Minsky’s 1967 implementation of a Universal Turing Machine, which, despite its momentous theoretical importance for the field of computer science, had never actually been built into a real-world computer. But in the decade or so after Minsky’s design, the earliest versions of Unix and DOS came into use, and their descendants are still with us today in the 21st century. Some of those systems have had bugs lurking beneath the surface for years or even decades.
Editor’s note: This article, originally published on June 18, 2021, has been updated with the Python tarfile vulnerability.
Here are 11 noteworthy and venerable bugs that were discovered in recent years.
Nissan telematics control module baseband vulnerability
Age: 7 years
Date introduced: 2010
Date fixed: 2017
Way back in 2011, security researcher Ralf-Philipp Weinmann discovered a recently introduced flaw in the baseband processor used in mobile phones that could conceivably be used in an attack: hackers could set up a fake cell tower, trick the phone into connecting to it, and then hijack its network connection. The flaw was corrected relatively quickly by cell phone manufacturers and then just as quickly forgotten about.
There was one problem: cell phones weren’t the only devices that used those chips. “Essentially, the same cellular baseband chipset was in the telematics unit in the Nissan Leaf and a variety of other vehicles,” says Jesse Michael, Principal Cyber Security Researcher at security firm Eclypsium. Several researchers (who would go on to join Eclypsium) discovered the vulnerability by experimenting with a car they got from a junkyard.
“This was a vulnerability that had been publicly known in a different market segment for almost seven years before we discovered it in the automotive segment,” said Michael. “Since it was in a widely different market segment that had its own complex supply chain, no one realized that the cars were also vulnerable to the exact same exploit as the phones.” It’s a real cautionary tale about industry siloing.
Python vulnerability first discovered 15 years ago still in play
Age: 15 years
Date introduced: 2007
Date fixed: 2007
Cybersecurity company Trellix has discovered that CVE-2007-4559, a vulnerability affecting Python’s tarfile module first identified in 2007, continues to affect hundreds of thousands of repositories.
“While investigating an unrelated vulnerability, Trellix Advanced Research Center stumbled across a vulnerability in Python’s tarfile module,” Kasimir Schulz, a vulnerability researcher for Trellix’s Threat Labs, wrote on the firm’s blog. “Initially we thought we had found a new zero-day vulnerability. As we dug into the issue, we realized this was in fact CVE-2007-4559.”
According to the National Institute of Standards and Technology (NIST), CVE-2007-4559 is a directory traversal vulnerability in the extract and extractall functions in the tarfile module in Python that allows user-assisted remote attackers to overwrite arbitrary files via a “..” sequence in filenames in a TAR archive.
Bad actors can create exploits with as few as six lines of code added to the tarfile module, which allows users to add a filter to parse and modify a file’s metadata before it is added to the tar archive, Schulz said. CVE-2007-4559 “is incredibly easy to exploit, requiring little to no knowledge about complicated security topics. Due to this fact and the prevalence of the vulnerability in the wild, Python’s tarfile module has become a massive supply chain issue threatening infrastructure around the world.” Trellix has found more than 300,000 repositories affected by the vulnerability.
Trellix has developed a scanning utility to identify the vulnerability and has patched a number of open-source repositories.
sudo’s Baron Samedit
Age: 9 years, 6 months
Date introduced: July 2011
Date fixed: January 2021
The sudo command is an important tool in any Unix admin’s toolkit, granting superpowered user privileges to those who have the correct permissions to invoke it. But with great power comes great responsibility, and it’s important that there be hedges around the command so that users don’t run amok through the system. For instance, you can invoke sudo in shell mode with the -c flag, which you can follow with a series of shell commands that will be executed with superuser privileges. This mode is potentially vulnerable to a buffer overflow attack, where special characters inserted into those commands trick the system into writing code outside the allocated memory buffer, potentially granting access to root privileges.
In general, sudo protects against such attacks by recognizing such special characters before they’re processed. However, in 2011, a vulnerability was accidentally inserted into sudo that made buffer overflow attacks possible, and it lurked in plain sight for nearly a decade. The flaw wasn’t in the sudo command proper, but instead in the auxiliary sudoedit command, which allows users to use superuser privileges to access and edit a file without granting full superuser privileges to the editor program itself. As outlined on the Qualys blog in January 2021, the vulnerability allows serious privilege escalation and patching it is crucial. Affected systems include almost all Unix variants, including Linux, Solaris, and macOS.
Linux GRUB2 Secure Boot hole
Age: 10 years
Date introduced: 2010
Date fixed: July 2020
When UEFI was introduced as a replacement for BIOS, it was deemed the cutting edge of security, with features designed to fight attacks that operated on the level of the bootloading software that starts up an operating system. Key to this is an interlocked chain of signed cryptographic certificates that verifies each bootloader program as legit, a mechanism known as Secure Boot. The root certificate for UEFI is signed by Microsoft, and Linux distributions put their own bootloaders, each with its own validated certificate, further down the chain.
But as CSO’s Lucian Constantin explains, GRUB2, a widely popular Linux bootloader with a UEFI-ready certificate, contains a buffer overflow vulnerability that can be exploited by malicious code inserted into in its configuration file. (While GRUB2 itself is signed, its configuration file, meant to be editable by local admins, is not.) This hole was spotted by Eclypsium, and while an attacker would need to have a degree of local control of the target machine to implement this attack, if they pulled it off successfully, they could ensure that they remain in control of that computer going forward each time it boots up, making it difficult to evict them from the system.
LionWiki Local File Inclusion
Age: 11 years, 11 months
Date introduced: November 2008
Date fixed: October 2020
LionWiki is a minimalist wiki engine, programmed in PHP; unlike many popular wiki engines, like the one underlying Wikipedia, LionWiki doesn’t use a database, and instead is entirely file-based. Since its goal is simplicity, this is one of its strengths, but it also makes a significant vulnerability possible.
In essence, the various files underlying a particular LionWiki instance are accessed by file and pathnames in the URL of the corresponding pages. This means that, with a correctly crafted URL, you could traverse the filesystem of the server hosting the LionWiki instance. There are URL-filtering provisions in place to block attempts to do this, but as Infosec Institute Cyber Range Engineer June Werner discovered, they could be defeated fairly easily.
One thing Werner notes is that this vulnerability persisted despite some attempts to correct it. “Some mitigations were first put in place in July of 2009, and then more extensive mitigations were put in place in January of 2012,” she notes. “Despite these mitigations, the code was still vulnerable to the same type of attack. This vulnerability stayed in the code for another eight years until it was rediscovered, along with a way to bypass the mitigations, in October of 2020.” After the bug was formally reported, it was patched by the developer.
Domain Time II man-on-the-side attack
Age: 14 years
Date introduced: 2007
Date fixed: April 2021
If two computers on the same network can’t agree on what time it is, the results can range from the annoying to the disastrous. This is a longstanding problem in computing, and one of the most mature and widely deployed enterprise solutions is a program known as Domain Time II, a closed-source application in use on Windows, Linux, and Solaris.
Domain Time II harbored for most of its existence a very serious vulnerability. At intervals or upon conditions that the user can set, the program sends UDP queries to an update server run by Greyware Automation Products, the software’s vendor. If the server replies with a URL, Domain Time II will run a program with administrator privileges to download and install an update from that URL.
The problem? If a malicious actor manages to reply to the query before Greyware’s update server does, that attacker can send its own reply, prompting Domain Time II to download whatever malware the attacker wants installed. In a true man-in-the-middle attack, the attacker would be intercepting communications in both directions; in contrast, this is what’s known as a man-on-the-side attack, in which the attacker can’t stop replies to its target machine getting through and so has to send its own reply more quickly. In practice, this means the attacker would need to already control a computer on the target’s local network to pull this off, but this attack represents a way an attacker could escalate their intrusion onto more valuable and secure machines within a local network. This vulnerability was spotted by the security firm Grimm, which noted that the flaw was present in versions of the software going back at least to 2007.
Linux SCSI subsystem bugs
Age: 15 years
Date introduced: 2006
Date fixed: March 2021
If you’re old school, you remember SCSI, a 1980s-era data transfer standard that might’ve been how your first hard drive connected to your IBM PC or classic Mac. It’s still in use in some contexts today, and Linux, always intended to be as flexible and universal as possible, still has an extensive SCSI subsystem for those systems that need it. These modules are available via what’s known as automatic module loading, in which the OS grabs and installs the system code it needs when it needs it—which is helpful if you find yourself plugging a SCSI drive into your Linux machine and don’t want to hunt down the necessary supporting code, but it’s also helpful to attackers who want to exploit errors in said code.
Cybersecurity consultancy Grimm posted an extensive breakdown of several bugs in this Linux SCSI code that they discovered in March 2021. One was a buffer overflow vulnerability that could allow a normal user to gain root privileges, and the others were errors where information from the kernel could be leaked to user space, and all could be used to get privileged information or as part of a DoS attack on the affected machine. Grimm dates the bugs back to 2006 and dryly notes that they’re “an indication of a lack of security-conscious programming practices that was prevalent at the time this code was developed.”
SIGRed
Age: 17 years
Date introduced: 2003
Date fixed: 2020
DNS is one of the underrated backbones of the internet, the system by which your computer knows what IP address correlates to any given URL. The system is hierarchical, with requests being sent up and down the pyramid looking for DNS servers that know the answer to the question, “Where is this computer?” As a result, DNS has been built into all major operating systems.
In 2020, Microsoft disclosed a critical vulnerability in its own version of DNS, which had been lurking in the code for 17 years, although there was no evidence that it had ever been exploited in the wild. The vulnerability, dubbed SIGRed by its discoverers at Check Point, was a buffer overflow flaw in Windows DNS servers that could be used triggered by exploit code tucked into a DNS packet’s signature. A malicious nameserver could send such packets in response to requests, bypassing most security protections and potentially gaining remote access to the Microsoft DNS server. The attack would be potentially wormable, meaning that it could be automated and spread without user intervention.
PuTTY heap overflow
Age: 20 years, 9 months
Date introduced: January 1999
Date fixed: October 2019
