During the last few days the case on the actions taken by a group of researchers from the University of Minnesota, since from the perspective of many, such actions in relation to the introduction of vulnerabilities in the Linux Kernel have no justification.
And even though a group University of Minnesot Researchersto publish an open letter of apology, whose acceptance of changes to the Linux kernel that was blocked by Greg Kroah-Hartman revealed details of patches submitted to kernel developers and correspondence with maintainers associated with these patches.
It is noteworthy that all problem patches were rejected At the initiative of the maintainers, none of the patches were approved. This fact makes it clear why Greg Kroah-Hartman acted so harshly, as it is unclear what the researchers would have done if the patches had been approved by maintainer.
In retrospect, argued that they intended to report the bug and they wouldn't allow patches to go to Git, but it's unclear what they would actually do or how far they could go.
In total, in August 2020, five patches were sent from the anonymous addresses acostag.ubuntu@gmail.com and jameslouisebond@gmail.com (a letter from James Bond): two correct and three including hidden errors, creating conditions for the appearance of vulnerabilities.
Each patch contained only 1 to 4 lines of code. The main idea behind the bad patches was that fixing a memory leak could create a condition for a double free vulnerability.
The project aims to improve the security of the patching process in OSS. As part of the project, we study potential problems with the OSS patching process, including the causes of the problems and suggestions for addressing them.
In fact, this study reveals some problems, but its aim is to call for efforts to improve the
patching process to motivate more work to develop techniques to test and verify patches, and finally to make the OS more secure.Based on these patches, we summarize their patterns, study the specific reasons why bug introduction patches are difficult to catch (with both qualitative and quantitative analysis), and most importantly provide suggestions for addressing the problem.
The first problematic patch fixed the memory leak by adding a call to kfree () before returning control in case of an error, but creating conditions to access the memory area after it was freed (use-after-free).
The specified patch was rejected by the maintainer, who identified the problem and indicated that a year ago someone had already tried to propose a similar change and it was initially accepted, but discarded the same day after identifying the vulnerability conditions.
The second patch also contained conditions for the post-release wear issue. The specified patch was not accepted by the maintainer, who rejected the patch due to another problem with list_add_tail, but did not notice that the "chdev" pointer can be freed in the put_device function, which is used next in the call to dev_err (& chdev -> dev ..). However, the patch was not accepted, albeit for reasons unrelated to vulnerability.
Interestingly, initially it was assumed that 4 out of 5 patches had problems, but the researchers themselves made a mistake and in a problematic patch, in their opinion, the correct solution was proposed, without the supposed conditions to use memory after launch.
In this work, we present the concept of «immature vulnerability» where a condition of vulnerability is lacking, but it can become a real one when the condition is implicitly
introduced by a patch for another bug.We also develop tools that help us find places of code that may suffer
of the bug introduction patches and suggest what might make these bug introduction patches difficult to detect.A week later, information was sent to the kernel developers with a proposal to discuss the possibility of promoting vulnerabilities under the guise of trivial fixes for memory leaks, but nothing was said about previous attempts to submit malicious patches.
The third patch was also rejected by the maintainer due to another bug without vulnerability (double application in pdev).