University of Minnesota Researchers Tried to Poison the Linux Kernel

Researchers from the University of Minnesota submitted intentional faulty code to the Linux kernel — and almost got away with it.

The name of said research paper was “On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits,” which was published February 10. The goal of the paper was to “investigate the insecurity of [open source software] from a critical perspective.” The approach involved submitting “hypocrite commits” (the paper’s wording), which were seemingly beneficial commits that actually introduced other critical issues.

Open source software, such as the Linux kernel “is extremely complex, so the patch review process often misses introduced vulnerabilities that involve complicated semantics and context.”

And so to prove their hypothesis, the writers of the paper, Qiushi Wu and Kangjie Lu intended to commit vulnerable code that would, in turn, introduce critical issues into the kernel, to measure the scientific probability of those patches being accepted into the software.

Let that sink in for a moment. The researchers, in the name of academia, decided to commit flawed code (that would, in turn, introduce other serious issues) into the Linux kernel, to prove they could do it.

The ramifications of this are profound.

Consider this. The Linux kernel is used by Fortune 500 companies around the world, it drives enterprise businesses and makes it possible for companies to not only introduce open source technology into their production pipelines but expand their capabilities beyond their wildest imaginations. Open source drives innovation in business.

At least one faulty patch made it into the kernel (in this case it was missing mutex unlock clearly).

Fortunately, kernel maintainer Greg Kroah-Hartman caught the behavior, and chastised the researchers on the Linux kernel developer’s mailing list:

You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work. Now you submit a new series of obviously incorrect patches again, so what am I supposed to think of such a thing?

Our community does not appreciate being experimented on, and being “tested” by submitting known patches that are either do nothing on purpose or introduce bugs on purpose. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here.

Because of these actions, the entire university was banned from submitting patches to the Linux kernel.

While free and open research lies at the heart of open source, this project walked a very fine line, one that could have had serious (and global) repercussions. Had their vulnerable patches been accepted into the Linux kernel, would the authors of the paper come forward to inform the kernel maintainers of what they’d done? Or would they have let it continue, to see just how far it would go?

But the research also points to another troubling factor. If malicious patches are easy to surreptitiously slip into complex software, how much has it been done already?

The researchers themselves concluded in their paper that open source projects should develop codes of conduct forbidding “hypocrite patches,” and that the projects should use robust testing and vulnerability discovery tools for incoming patches.

In the end, it’s important to remember the profound and lasting effect the Linux kernel has on businesses across the land. To that end, the responsibility of submitting code to that project should be taken quite seriously.