‘Memsad’ software rot threatens to leak your digital secrets

VANCOUVER—If coding and updating software is like building and maintaining a house, one might say software that leaks passcodes is like a home with a rotting foundation—but you don’t know it.

Ilja van Sprundel, the director of penetration testing at security research company IOActive, says he’s detected a significant amount of rot in the foundation of a wide swath of commonly used software code.

At the Chaos Communication Congress in December, and then again on March 19 here at the CanSecWest conference, van Sprundel named a particular case of code rot—one that essentially enables hackers to pluck mission-critical digital secrets directly from the software—memsad, a pun on the “memset” function to clear memory.

Memsad causes software to leak the digital keys that protect encrypted emails, encrypted storage, digital rights management, and even authentication mechanisms such as those used in two-factor authentication, van Sprundel said. It appears when software code is compiled, or converted from human-readable code language into binary zeros and ones, and it presents two vulnerabilities.

“[Memsad] is literally everywhere. It’s in the stuff that everybody uses. If we can’t get it right, what hope is there for mere mortals?”—Ilja van Sprundel, director of penetration testing, IOActive

The first vulnerability stems from compilers’ failure to always instruct software to clear mission-critical data from the computer’s memory. Researchers have known about this vulnerability for more than 30 years. But without an easily reproducible way to extract the data, not much has been done to address the problem.

The second vulnerability, van Sprundel’s research shows, is more likely to appear when mission-critical data is present in memory. It can be exploited to extract the data from the computer’s memory, exposing passwords, keys, and tokens we use to protect our data.

“If you’re on the client side, it’s not that bad,” van Sprundel says, because the secrets leaked are confined to that specific computer. But if it’s a leak in a cloud-computing network, “it could be really bad. It could be on the same level of Heartbleed,” a catastrophic vulnerability in OpenSSL that allowed attackers to bypass traditional security measures, he told The Parallax.

“[Memsad] is literally everywhere. It’s in the stuff that everybody uses,” he says. “If we can’t get it right, what hope is there for mere mortals?”

Van Sprundel considers memsad a major problem in software security because it causes leaks of some of the most critical safety mechanisms in use today: encrypted passwords, authentication keys, and session tokens.

Memsad also affects software that most of the Internet and modern computing relies on to communicate: OpenSSL (a general-purpose, open-source cryptographic library used to encrypt); BIND (the most widely used Domain Name System software, which helps connect computers and phones to addresses on the Internet); DHCP (used to assign and configure Internet addresses); MIT Kerberos and Heimdal Kerberos (two slightly different systems which both use a three-step process to encrypt network data sent across otherwise insecure networks); PHP (a nearly ubiquitous computer language for writing short programs known as scripts); Nginx (a multipurpose, open-source Web server software in use by major tech companies such as Google, Facebook, Microsoft, and Autodesk); and Rsync (used to synchronize files across Linux computers).

These various software packages help power household name programs and operating systems, and as such, memsad could touch nearly the entire Internet and computing world. Netflix and NASA use Nginx to run their websites. Versions of Kerberos exist in Microsoft’s Windows and Xbox Live, Apple’s Mac OS X, Unix, Linux, and the POP and IMAP protocols, which help emails reach their recipients. PHP runs on nearly 80 percent of all websites.

Van Sprundel says that because memsad is a two-stage vulnerability, it’s very hard to discern whether it’s previously been exploited. However, in his talk, he said he was able to find nine zero-day vulnerabilities across the affected software that he could use in exploiting memsad. The potential for harm is vast, he says. And even after code is updated, data secrets may still be exposed by memsad because of the challenges in getting all the systems that use the affected software fully patched before getting hacked.

Another tricky aspect of detecting and dealing with memsad is that it doesn’t fundamentally break the software it affects. That is, just as a house with a rotten foundation will likely continue standing, the software will continue working; it just won’t protect data secrets as well as it once had.

Prioritizing which secrets get cleared from the computer’s memory, and how fast it’s supposed to clear those secrets, is also a matter of much debate.

“This is an old problem, of course,” Chris Wysopal, chief technology officer at software security evaluation company Veracode, wrote in an emailed statement to The Parallax. While Microsoft discovered the problem of not clearing secrets from memory and worked a solution into Microsoft Windows in 2002, stopping secrets from being leaked by the software compiler requires more aggressive action from software developers.

“Any code dealing with secrets is security-critical. It should be reviewed by someone who understands secure coding well, which will hopefully detect these types of scenarios,” Wysopal wrote. “I have seen plenty of code where there isn’t even the memset call to overwrite secrets.”

Thus far, van Sprundel says only MIT Kerberos and Nginx have patched their software in response to memsad alerts. And Matt Caswell, a member of the OpenSSL Management Committee and one of the few people in the world paid to maintain the mostly volunteer OpenSSL project, wrote in an email that OpenSSL uses a different method to clear security secrets from memory than the memset function at the heart of the memsad vulnerability.

“The OpenSSL project is well aware of the risks of memset being optimised out by the compiler. For this reason, we do not use this call for security-sensitive operations,” Caswell said. “This clears memory in a security-safe manner.”

Other affected software vendors, including people who help maintain BIND, DHCP, Heimdal Kerberos, PHP, and Rsync, did not respond to requests for comment.

The tension between making software run faster and making it more secure is at the heart of the memsad problem, van Sprundel argues.

“Compiler optimization and cryptography, at the present time, are mutually exclusive. It doesn’t work,” he says. “We need to have a new way of marking a buffer or temporary storage as sensitive.”

Dan Kaminsky, a security researcher known for his work finding a fundamental security flaw in DNS, and a former co-worker of van Sprundel’s at IOActive, agrees that the problem is hard to solve, and only going to get harder in the era of hardware vulnerabilities such as Spectre. He says he worries that the complexity of the memsad problem will require equally complex solutions. And he compares potential solutions to sandboxing, or attempting to wall off, the vulnerabilities.

“If sandboxes worked, we wouldn’t have cared about Flash. It was a pretty expensive thing to do that—well, for Adobe, anyway,” he said in an emailed statement. “I do expect that the tension between compiler goals and security requirements is going to yield some pretty nasty things over the next few years.”

Disclosure: CanSecWest’s organizers covered part of The Parallax’s conference travel expenses.