Author | Xu Xuanjuan“Even if you can provide evidence that those patches are effective, why are we actually wasting time doing extra work?”
Linus Torvalds must be furious.
Recently, Greg Kroah-Hartman, the maintainer of the Linux kernel stable branch, blacklisted the University of Minnesota (UMN), prohibiting it from submitting patches to the mainline Linux kernel. The reason is that UMN intentionally submitted suspicious code with security implications and conducted other “experiments” under the guise of research.
1Not the first controversy
Not long ago, Qiushi Wu, a PhD student in Computer Science and Engineering at the University of Minnesota (undergraduate at the University of Science and Technology of China), and Assistant Professor Kangjie Lu (undergraduate at Peking University) wrote a paper aimed at improving the security of the patching process in open-source software, titled “On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits.”
It is reported that Qiushi Wu obtained his bachelor’s degree in Information Science and Engineering from the University of Science and Technology of China in 2018, focusing on the application of program analysis techniques in operating systems like the Linux kernel. In February of this year, Qiushi Wu uploaded the aforementioned paper to GitHub (which has since been deleted) and planned to discuss it at the 42nd IEEE Symposium on Security and Privacy in May.
The paper explores the possibility of hiding security vulnerabilities in patches for open-source projects, hoping to guide maintenance teams to more scientifically assess such patches and make correct merging judgments.
In the study, the research team demonstrated the practicality of introducing vulnerability patches through experiments, which was considered to introduce erroneous conditions in operating system software. Moreover, in the paper, they publicly disclosed feasible methods for inserting vulnerabilities into the Linux kernel and other open-source projects, stating that the success rate of injecting vulnerabilities into various open-source projects was nearly 60%. This sparked significant security controversy at the time.
In response, Qiushi Wu explained on December 15 last year, “We did not and do not intend to introduce any errors or vulnerabilities into the Linux kernel. All erroneous patches were only retained in email communications and were not adopted or merged into any Linux branches, as confirmed by the maintainers. Therefore, no Linux users would be affected.”
At the same time, Qiushi Wu also stated that the experiment had passed the Institutional Review Board (IRB) review of UMN, which determined that the project did not involve human research and therefore did not undergo further ethical review.
However, recently, researchers from the University of Minnesota submitted a new round of patches, claiming to come from “a new static analyzer,” which annoyed Greg and led to the entire University of Minnesota being blacklisted.
“I have always wanted to do this, but recent events finally forced me to do it,” Greg stated. In response, Aditya Pakki, a PhD student in Computer Science and Engineering at the University of Minnesota, expressed his anger and emailed Greg:
Greg, I kindly ask you to stop these defamatory and barbaric accusations.These patches were sent as part of my new static analyzer, and clearly, its sensitivity is not high. I submitted the patches hoping to get feedback. We are not experts in the Linux kernel, but your repeated statements are annoying.This is clearly a misstep, but your preconceived bias is so strong that your accusations are unfounded and have not provided any positive or beneficial feedback. Since it is not only unwelcome but also scares newcomers and non-experts, I will no longer submit patches.
Greg also emphasized in his reply email that the fault lies with the University of Minnesota, and the community is not their testing subject:
You and your team have publicly admitted to sending known erroneous patches to see the kernel community’s reaction and based on that published a paper.Now you have submitted a series of obviously erroneous patches, how should I view this matter?These patches are clearly not created by any intelligent static analysis tool, as they are all the result of completely different patterns, and all of these clearly do not fix anything. So, what else can I think of besides you and your team continuing to experiment on the kernel community’s developers by submitting these meaningless patches?Anyone with a certain understanding of the C language can see that the patches you submitted are completely ineffective, so believing that a tool created these patches and then thinking they are valid “fixes” is entirely your negligence, not ours. The fault lies with you; our work is not to be the test subjects of the tools you create.Our community does not like to be experimented on, nor do we like to be “tested” by submitting known patches that either do nothing intentionally or intentionally introduce bugs. If you want to conduct such research, I suggest you find another community; you are not welcome here.Therefore, I now have to ban your university from any future contributions and remove your previous contributions, as they were clearly submitted maliciously with the intent to cause problems.
After this, the official account of the UMN Computer Science Department also released the following statement on Twitter, indicating that the research project has been suspended and plans to investigate the approval process of the project to determine if remedial actions and possible safeguards are needed.
Today, the leadership of the Department of Computer Science and Engineering at the University of Minnesota learned that a faculty member and a graduate student are researching the security of the Linux kernel. Due to the research methods used, which have raised strong concerns in the Linux kernel community, the university has been banned from contributing to the Linux Kernel until now.We take this very seriously and have immediately suspended this research. We will investigate the methods and approval processes of this research to determine appropriate remedial actions and take measures to prevent potential future issues if necessary. We will report the findings of the investigation to the community as soon as possible.Mats Heimdahl, Department HeadLoren Terveen, Deputy Department Head
2Wasting Community Time or Valuable Research?
The Linux kernel is one of the largest software development projects to date, with a total code volume exceeding 28 million. The Linux kernel maintenance team receives a large number of patches submitted daily from contributors around the world and from different fields, reviewing the content before officially merging the results. The behavior of the University of Minnesota research team has undoubtedly been strongly condemned by Linux contributors and maintainers.
Leon Romanovsky, a developer with extensive experience in the Linux kernel, immediately demanded that the University of Minnesota stop submitting known ineffective patches, stating, “This is wasting our time.” Some netizens even claimed that this paper is deliberately misleading, attempting to exaggerate its contributions. “Many people in academia are just trying to get certificates.”
Abhi Shelat, an associate professor of computer science at Northeastern University in Boston, stated, “Academic research should not waste the community’s time. If you think this research is worth doing, you should contact UMN’s Institutional Review Board.” Shelat also urged members of the Linux community to question UMN’s IRB to determine whether the experiment was adequately reviewed.
In response, Qiushi Wu previously stated that this work indeed wasted the time of maintainers, and although the team had carefully considered this issue, they did not find a better solution, but they would strive to avoid this problem by streamlining patches.
However, some developers outside the Linux kernel community believe that the focus should be on the security issues of the Linux kernel code rather than the “ridiculous” behavior of researchers.
If UMN had not attracted any attention, would they have been discovered? Have other malicious actors done similar things without being caught?
“This seems to indicate that any hacker organization or individual can place their attacks within the kernel. Suppose they contributed 99.9% useful code, solved real problems, built trust over the years, and wrote few undetectable malicious vulnerabilities. Then everyone thinks those vulnerabilities are just ordinary bugs.”
Filipo Valsorda, a cryptography and software engineer at Google, stated on Twitter that just as Linux kernel maintainers said they could not determine whether patches were malicious, they must rely on email address domains. Rather than condemning scholars, it should be more concerning to make trust decisions based on determined code correctness.
Katie Moussouris, CEO of Luta Security, also expressed a similar view, stating that this reaction is an “emotional overreaction” and believes these findings are valuable from a national security perspective.
After intense debate, Greg now stated that he would restore all patches submitted by the team and review them again to determine their validity. Until then, the team’s patches will still be deleted to ensure that no issues are introduced into the codebase.
Some of these patches can be “easily” restored, while 68 need to be manually checked for restoration, some of which cannot be restored yet. Once these changes are confirmed to be valid, the University of Minnesota research team can resubmit.
But in the end, Greg still stated, “Even if you can provide evidence that they are effective, why are we actually wasting time doing extra work?”
Further Reading:https://fosspost.org/researchers-secretly-tried-to-add-vulnerabilities-to-linux-kernel/https://www.theregister.com/2021/04/21/minnesota_linux_flaws/
Today’s Recommended Article
Click the image below to read
3-Year Iteration of Technology Stack: Why Can’t We Programmers Keep Up with the Industry?
Event Recommendation
Today, microservices are prevalent. These microservices often run a large number of Kubernetes Pods and virtual machines (VMs) simultaneously. Moreover, containers cannot currently replace traditional VM deployment forms. Therefore, providing a unified infrastructure based on this is a challenge for developers and managers. VMware Cloud Foundation with Tanzu is designed to address this issue. Additionally, VMware has integrated Kubernetes capabilities into vSphere, respecting the traditional experiences of developers and vSphere administrators.
We have provided a white paper on “VMware vSphere with Kubernetes Basics”; scan the QR code below to learn more details:
Click to reduce bugs👇