In a rare, revolutionary decision, the proponents of the Linux kernel project imposed a ban on the University of Minnesota (UMN) from contributing to the open-source Linux project.
The move comes after a group of UMN researchers were caught sending a series of malicious code commits or patches that deliberately introduced security vulnerabilities into the official Linux code base as part of their research activities.
In addition, the maintainers of the Linux kernel project have decided to return to any code committees that have ever been sent from a @ umn.edu email addresses.
Malicious committees have been massively revoked, UMN researchers banned
Today, a major Linux kernel developer, Greg Kroah-Hartman, banned the University of Minnesota (UMN) from contributing to the open-source Linux kernel project.
Kroah-Hartman has also decided to cancel all committees sent from any UMN email address so far.
The developer’s justification for taking this step is:
“He is committed to @ umn.edu It was found that the addresses were sent in “bad faith” to try to test the core community’s ability to analyze the “malicious known” changes. “
“For this reason, all references in this group must be returned from the kernel tree and will need to be reviewed again to determine if they are in fact a valid correction.”
“Until the completion of that work, [we are removing] this change to ensure that no problems are introduced into the code base, “Kroah-Hartman said in a series of published emails.
In February 2021, UMN researchers published a research paper entitled “Open source insecurity: the widespread introduction of vulnerabilities through hypocritical commitments. “
The aim of this research was to deliberately introduce known security vulnerabilities into the Linux kernel, by sending malicious or insecure patches of code.
As BleepingComputer has seen, researchers demonstrate many examples of cases in which they have introduced known vulnerabilities by causing these “hypocritical” patches to commit:
“It simply came to our notice then. The patch is apparently valid because it cancels pf-> disc-> tail after the indicator is released. “
“However, some functions such as pf_detect () and pf_exit () are named after this cancellation and would still derive this pointer without checking its status, leading to the NULL pointer “, said the UMN researchers from the state.
As BleepingComputer has seen, there are hundreds of commitments that claim to be “patches” that have been canceled as part of this process:
UMN researchers call accusations “slander”
UMN researcher Aditya Pakki soon pushed back, urging Kroah-Hartman to refrain “from making savage accusations bordering on slander.”
Pakki wrote:
I respectfully ask you to stop and stop making wild accusations bordering on slander.
These patches were sent as part of a new static analyzer that I wrote and its sensitivity is obviously not great. I sent patches hoping to get feedback. We are not experts in the Linux kernel and making these statements repeatedly is disgusting to hear.
Obviously, it is a wrong step, but your preconceived notions are so strong that you make accusations without merit and do not offer us any benefit of doubt. I will no longer send patches because of the attitude that is not only unpleasant, but also intimidating for beginners and non-experts.
To which Kroah-Hartman responded that the Linux kernel developer community does not appreciate the fact that it was experienced in this way.
“If you want to do such work, I suggest you find a different community to run your experiments on, you’re not welcome here,” Kroah-Hartman said.
“Because of this, I will now have to ban all future contributions from your University and withdraw your previous contributions, because they were obviously presented in bad faith with the intention of causing problems,” he continued.
Last year, UMN researchers compiled a detailed document of frequently asked questions stating that the purpose of this research was to improve the security of the patch process in open-source software, demonstrating the practicality of introducing error patches. .
The researchers also stated that any patch suggestions were made through email exchanges and never reached a branch of code or the Linux kernel.
According to the document, the University’s IRB established that this was not human or ethically harmful research and, as such, authorized the research activities.
Although, researchers have sincerely apologized to Linux supporters for wasting their time reviewing “hypocritical” patches:
“We would like to sincerely apologize to the maintainers involved in the proper patch review process; this work has really wasted their precious time.”
“We have carefully analyzed this problem, but we could not find a better solution in this study,” say the researchers.
Brad Spengler, president of Open Source Security Inc., analyzed the issue, calling it an “excessive reaction” from Linux kernel maintainers.
Spengler points out that many people, including himself, called suspicious patch submissions to Linux maintainers last year, but so far they have not been mass-acted.
What a mess, several people (including me) tried to warn them last year: https://t.co/kl7tfKAqXj and now this exaggerated reaction: https://t.co/twOgboRFIR will cause a lot more work for everyone
– Brad Spengler (@spendergrsec) April 21, 2021
“… this exaggerated reaction is terrible, it comes back to committing long before any research, eliminating CAP_SYS_ADMIN checks that have been added, etc … That’s unexpected, “Spengler continued in the same thread.
Spengler also told BleepingComputer that not all returned patches were necessarily malicious, warning that a decision to return all patches could reintroduce errors:
Is it one thing to do that backstage review and commit only the result of that review, but to knowingly reintroduce dozens of vulnerabilities to “take a stand”? Come on.”
When contacted by BleepingComputer, Kroah-Hartman chose not to comment further on the situation.
BleepingComputer contacted the University of Minnesota for comment before publishing this article, but I didn’t hear it at the time.
The university has now issued a public statement and suspended this line of research, pending further investigations:
The research method used has raised serious concerns in the Linux Kernel community and, as of today, this has led to the University’s ban on contributing to the Linux Kernel.
– UMNComputerScience (@UMNComputerSci) April 21, 2021
Updates:
April 21 at 15:07 ET: excerpts from frequently asked questions compiled by UMN researchers have been added.
April 22 at 1:26 AM ET: Twitter has been added with the statement from the University of Minnesota, received hours after publication.