In 2021, Pontus Johnson, a computer science professor at the KTH Royal Institute of Technology in Stockholm, Sweden, discovered a related vulnerability in the universal Turing machine (UTM) that could execute arbitrary code. Shockingly, the vulnerable code has been around for nearly 54 years — and there is no patch available, and no expectation of one.

Fortunately, the universal Turing machine (UTM) is a conceptual simulation design proposed by the late ARTIFICIAL intelligence scientist Marvin Minsky in 1967, and although it has theoretical implications for the field of computer science, it has never actually been built into a real-world computer.

But a decade after Minsky’s conceptual simulation, early versions of Unix and DOS emerged, and the descendants of those two operating systems are still with us today, some of them with bugs that have been lurking for years or even decades.

Here are 10 of the most notable old bugs discovered in recent years:

Baseband vulnerability in the Nissan telematics control module

Incubation period: 7 years;

Introduction time: 2010;

Restoration time: 2017;

Back in 2011, security researcher Ralf-Philipp Weinmann discovered a flaw in the baseband processors used in mobile phones. Here’s an introduction to baseband attacks, a type of threat against mobile devices. The baseband processor, independent of the mobile operating processor, is primarily responsible for deploying the GSM or 3G stack to the device. All calls and data first pass through the baseband, giving the operating system processor the necessary processing information. An attacker who destroys this base band can gain a huge advantage because there are no forensics tools in this layer.

Imagine such a baseband attack: a hacker could set up a fake cell tower, trick a phone into connecting to it, and then hijack its network connection. The phone maker was relatively quick to correct the bug, and it was soon forgotten.

But there’s a catch: Phones aren’t the only devices using these chips. Essentially, the same cellular baseband chipset is used in the telematics unit of the Nissan Leaf and a variety of other vehicles, said Jesse Michael, principal cybersecurity researcher at security firm Eclypsium. Several researchers discovered the bug by experimenting with cars they got from junkyards.

The flaw was disclosed in various market segments for nearly seven years before it was discovered in the automotive sector. Being in a very different market segment and with its own complex supply chain, no one realized that cars were vulnerable to exactly the same attacks as phones. This is a true cautionary tale about an industry island.

Sudo’s Baron Samedit vulnerability

Incubation period: 9 years and 6 months;

Introduction time: July 2011;

Restoration date: January 2021;

The sudo command is an important tool in any Unix administrator toolkit and grants superuser privileges to those who have the right permissions to invoke it. But “with great power comes great responsibility,” and it’s important to put hedges around commands so that users don’t run amok in the system. For example, you can call sudo in shell mode using the -c flag, and then you can execute a series of shell commands executed with superuser privileges. This pattern can be vulnerable to buffer overflow attacks, where special characters inserted into these commands can trick the system into writing code outside of the allocated memory buffer, which can cause an attacker to gain root privileges.

Typically, suDO recognizes these special characters before execution to prevent such attacks. However, in 2011, a vulnerability was accidentally inserted into sudo that made buffer overflow attacks possible, and it remained latent for nearly a decade. The flaw is not in the sudo command itself, but in the auxiliary sudoedit command. Any local user (ordinary and system users, sudoers and non-sudoers) can exploit this vulnerability without authentication (i.e. the attacker does not need to know the user’s password). This vulnerability can be used for indiscriminate authorization of ordinary users. Vulnerabilities pose a serious threat to data confidentiality and integrity as well as system availability.

The affected systems include almost all Unix variants, including Linux, Solaris, and macOS. Today, this vulnerability has been assigned to CVE-2021-3156 with a risk rating of 7, so fixing it is critical.

Linux Grub2 BootHole vulnerability

Incubation period: 10 years;

Introduction time: 2010;

Restoration date: July 2020;

UEFI was once considered the cutting edge of security when it was introduced as a replacement for BIOS, with features designed to counter attacks that run at the boot loading software level that boots the operating system. The key is an interlocked chain of signed encrypted certificates that verifies that each Boot loader is legitimate, a mechanism known as Secure Boot. UEFI’s root certificate is signed by Microsoft, and Linux distributions place their own boot loaders further down the chain, each with its own verified certificate.

Security research firm Eclypsium has revealed a new vulnerability in the Secure Boot feature, which it has named “BootHole.” It is specifically found in Secure Boot’s GRUB2 file, which allows an attacker to gain “near complete control” over a victim’s system. Once successfully exploited, it will allow hackers to write arbitrary program code and replace it with a malicious bootloader program, weakening UEFI Secure Boo’s safe boot verification and allowing malicious programs to invade the computer. And both Linux and a fairly large number of Windows operating systems are affected by this vulnerability in the UEFI firmware.

The LionWiki local file contains a vulnerability

Incubation period: 11 years and 11 months;

Date of introduction: November 2008;

Restoration Date: October 2020;

LionWiki is a minimalist wiki engine, written in PHP; Unlike many popular wiki engines, such as the underlying Wikipedia engine, LionWiki does not use databases, but is based entirely on files. Due to its goal of simplicity, being completely based on files is one of its advantages, but it also creates a major security hole.

Essentially, the various files under a particular LionWiki instance are accessed through the file and pathname in the corresponding page URL. This means that, with the properly constructed URL, you can traverse the file system hosting the LionWiki instance server. There are URL filtering rules that can prevent such attempts, but it’s easy to get around URL filtering.

June Werner, Infosec Institute Cyber Range engineer, noted that the vulnerability has persisted for a long time despite some attempts to fix it. Some mitigation measures were introduced for the first time in July 2009, followed by more extensive mitigation measures in January 2012. However, despite these mitigation measures, the code is not protected against the same type of attack. The vulnerability remained in the code for another eight years until October 2020, when a way around these mitigation measures was rediscovered. After the official report, the developers have fixed the bug.

Domain Time II man-on-the-side (MOTS) attack

Incubation period: 14 years;

Introduction time: 2007;

Restoration date: April 2021;

If two computers on the same network can’t agree on the timing, the results can be annoying or terrible. Time synchronization is a long-standing problem in computing, and the most mature enterprise solution is Domain Time II, a closed-source application that is widely deployed on Windows, Linux, and Solaris.

Domain Time II has been hiding a very serious bug almost from birth. From time to time, or under conditions that the user can set, the software sends UDP queries to update servers run by its vendor, Greyware Automation Products. If the server replies to the URL, Domain Time II runs the program as an administrator to download and install updates from the URL.

What’s the problem? If the malicious actor manages to reply to the query before Greyware’s update server, the attacker can send his fabricated reply, prompting Domain Time II to download whatever malware the attacker wants it to install. In a true man-in-the-middle attack, the attacker intercepts both ways; The Domain Time II attack, by contrast, is a so-called man-on-the-side attack: the attacker cannot intercept the reply sent to his target, so he must send his own concocted reply before a legitimate one can be sent. In practice, this means that an attacker would need to already control a computer on the target’s local network to do so, but this attack means that an attacker can upgrade their intrusion to other, more valuable and secure machines on the local network. Grimm, the security company that discovered the flaw, noted that the vulnerability dates back to at least 2007 versions of the software.

Linux SCSI subsystem vulnerability

Incubation period: 15 years;

Introduction time: 2006;

Restoration date: March 2021;

If you’re a nostalgist, you might remember SCSI, the 1980s data transfer standard and probably the way your first hard drive hooked up to an IBM PC or classic Mac. Today, SCSI is still used in some environments, and Linux, which has always sought flexibility and versatility, still provides an extended SCSI subsystem for systems on demand. These modules are available through what’s known as automatic module loading, from which the operating system can grab and install the system code as needed — useful if you want to mount a SCSI hard disk to a Linux machine without looking for the necessary supporting code, but also to help an attacker exploit vulnerabilities in the code.

In March 2021, cybersecurity consulting firm Grimm published several vulnerabilities found in Linux SCSI code. One buffer overflow vulnerability allows regular users to gain root access, the others can leak information from the kernel into user space, and all can be used to obtain confidential information or as part of a DoS attack on the affected machine. Grimm said the bugs, which date back to 2006, reflect a lack of security considerations in programming practices that were common when the code was developed.

Windows DNS SIGRed vulnerability

Incubation period: 17 years;

Introduction time: 2003;

Restoration date: 2020;

DNS is one of the underrated backbone of the Internet, the system by which a computer resolves an associated IP address from a given URL. DNS is hierarchical, and domain name resolution requests flow up and down the layers of the DNS pyramid looking for answers to the question “Where is this computer? This problem is the DNS server. As a result, DNS is built into almost all major operating systems.

In 2020, Microsoft revealed a serious vulnerability in its own version of DNS that had been lurking in the code for 17 years, although there is no evidence that it had been widely exploited. Known as “SIGRed” by the Check Point researchers who discovered the vulnerability, it is a buffer overflow vulnerability in Windows DNS servers that can be triggered by vulnerability exploit code hidden in DNS packet signatures. A malicious name server can respond to such packets with a domain name resolution request, bypassing most security measures and obtaining remote access to Microsoft’s DNS server. The attack can also be wormed, meaning it can be automated and spread without user intervention.

PuTTY heap overflow vulnerability

Incubation period: 20 years and 9 months;

Introduction time: January 1999;

Restoration date: October 2019;

PuTTY is a free, open source suite of tools that includes a serial console, terminal emulator, and various network file transfer applications with BUILT-IN SSH and various other encryption schemes. It was originally released to bring the system-by-system toolset that Unix administrators typically use to Windows and classic Mac OS, but its scope has expanded and it is now widely used on Unix systems as well. While PuTTY is designed to protect network connections, it turns out that its core code has a heap overflow vulnerability, another form of buffer overflow, that can be triggered by an excessively short SSH key, causing PuTTY to crash and even remote code execution.

The bug was submitted to HackerOne as part of a bug bounty scheme launched by the EU’s EU-Fossa project; It earned a $3,645 reward for the submitter, as well as a thank-you from the PuTTY team. The PuTTT team pointed out that the vulnerability existed in an early version of the PuTTY source code they had back in 1999.

Win32k sys loopholes

Incubation period: 23 years;

Introduction time: 1996;

Restoration date: 2019;

Two major vulnerabilities were detected in the Win32 API of Microsoft Windows in 2019. The first was a user-after-free vulnerability discovered in April, in which programs can exploit an operating system coding error to access supposedly protected system memory. Security researchers discovered the flaw when malicious hackers tried to use it to take control of computers in the wild. Another vulnerability, discovered in December, was a power-lifting vulnerability lurking in the operating system’s window-switching feature; Like the former, the vulnerability was discovered during an active attack that simulated keystrokes to create a memory leak.

Both vulnerabilities originated in the early days of the Windows operating system. Kaspersky senior security researcher Boris Larin explained,

The problem stems from when WIN32K debuted in Windows NT 4.0, when most of Win32’s graphics engine was moved from the user level to the kernel to improve performance.

While those two specific vulnerabilities have since been fixed, decisions Microsoft made years ago have had broader consequences — and they may be lasting. Over the years, WIN32K components have been responsible for more than half of the kernel security holes found in Windows.

PrintDemon loopholes

Incubation period: 24 years;

Introduction time: 1996;

Restoration date: May 2020;

Printers are a common pain point in the IT industry because there are so many different kinds and they are not made by the same vendors that make computers and operating systems, yet users expect “plug and play”. Microsoft, in particular, made it relatively easy to install printer drivers in its early days. But the recent discovery of a bug called PrintDemon suggests they may have acted too quickly in the 1990s, and are still paying the price today.

At the heart of the vulnerability are three facts: non-administrative users can add printers to Windows machines; The underlying mechanism makes it possible to print to a file rather than a physical printing device; Key print services on Windows run with SYSTEM permissions. This means that, done correctly, you can construct a “printer” driver that can create files (even executables) anywhere on the file system (or even the privileged directory). Hackers have created numerous exploits over the years to exploit these design flaws — Stuxnet, it turns out, is one of them — but PrintDemon, discovered in 2020, is particularly bad, and exists because Microsoft’s fixes over the years have been patches rather than a complete refactoring of the entire printing subsystem.

As Winsider puts it,

By making very small changes to the file system, you can replicate/write files that are not owned by any process, especially after a restart. With a well-designed port name, you can ask the Spooler process to place (portable executable) files anywhere on disk for you.

Study the significance of vulnerability age

Had it not been for such a list, it might not have occurred to you that your computer might have been hacked as a result of the Clinton-era printer subsystem bug. It is of practical importance to know the age of these vulnerabilities. “One of the things we have to do when we find a vulnerability in our independent research work is try to determine how long the vulnerability has existed,” said Adam Nichols, Grimm’s lead vulnerability researcher. Unfortunately, this hasn’t become the industry standard, but I’ve heard other researchers do it sometimes. Putting extra effort into finding out how long a bug is dormant is not part of your job, but I think it’s an important part of your research.”

Sandy Clark’s research shows that extensive code reuse creates a huge known vulnerability attack surface, and vulnerabilities lurking in long-used code bases may eventually evolve into exploits. This runs counter to traditional software engineering dogma, which holds that most vulnerabilities will be fixed as soon as a code base encounters real-world problems and attacks early in its use. But as it turns out, familiarity breeds contempt!