Linux banned University of Minnesota for sending buggy patches

Topic

New Reply

[Alex5723]

The University of Minnesota submitted buggy patch to Linux kernel as part of research paper

Linux has banned UMN from submitting Linux updates.

Greg KH on Tweeter

All contributions by this group of people need to be reverted, if they
> > have not been done so already, as what they are doing is intentional
> > malicious behavior and is not acceptable and totally unethical. I’ll
> > look at it after lunch unless someone else wants to do it…
>
> A lot of these have already reached the stable trees. I can send you
> revert patches for stable by the end of today (if your scripts have
> not already done it).

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?…

UMN have send an apology letter :

April 24, 2021
An open letter to the Linux community

Dear Community Members:

We sincerely apologize for any harm our research group did to the
Linux kernel community. Our goal was to identify issues with the
patching process and ways to address them, and we are very sorry that
the method used in the “hypocrite commits” paper was inappropriate. As
many observers have pointed out to us, we made a mistake by not
finding a way to consult with the community and obtain permission
before running this study; we did that because we knew we could not
ask the maintainers of Linux for permission, or they would be on the
lookout for the hypocrite patches. While our goal was to improve the
security of Linux, we now understand that it was hurtful to the
community to make it a subject of our research, and to waste its
effort reviewing these patches without its knowledge or permission.

We just want you to know that we would never intentionally hurt the
Linux kernel community and never introduce security vulnerabilities.
Our work was conducted with the best of intentions and is all about
finding and fixing security vulnerabilities….

• This topic was modified 4 years ago by Alex5723.
• This topic was modified 4 years ago by Alex5723.

5 users thanked author for this post.

doriel, Charlie, Bill C., OscarCP, SueW

Reply | Quote

Replies

If what happened is exactly as described in that tweet, then it is unbelievably irresponsible. I wonder if they did that a UMN for the usual bad academic reason: to have one more paper published to list in their CVs.

Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

Reply | Quote

That is a typical non-apology apology by an organization that clearly believes it was right in what it did. I am glad they are banned.

1 user thanked author for this post.

OscarCP

Reply | Quote

OscarCP wrote:

what happened is exactly as described in that tweet

What has happened is exactly as described in that tweet and UMN’s apology verifies that.
There were 190 such bogus patches. All have been reverted by now.

Reply | Quote

[Charlie]

Does anyone know the timeline these buggy patches were issued?  Recently or some time ago?

Edit:  Have these buggy patches been dealt with and corrections made or whatever?

Being 20 something in the 70's was far more fun than being 70 something in the insane 20's

• This reply was modified 4 years ago by Charlie.

Reply | Quote

Very invasive method for research paper, but the outcome seems clear to me – you cannot inject malicious code into open-source software. At least not into such large open-source community as Linux kernel is. Thats the real power of the open-source 🙂 their ban from this project is adequate.

Dell Latitude 3420, Intel Core i7 @ 2.8 GHz, 16GB RAM, W10 22H2 Enterprise

HAL3000, AMD Athlon 200GE @ 3,4 GHz, 8GB RAM, Fedora 29

PRUSA i3 MK3S+

1 user thanked author for this post.

OscarCP

Reply | Quote

Here, in more detail, is what happened, and it was definitely pretty bad:

The UMN group sent “test” patches that converted three potential kernel vulnerabilities into actual ones, infecting the actual stable releases, then warned the kernel team about it once that was done, offering good patches to fix the bad ones and also eliminate the vulnerabilities. Then they presented these results at a conference and had the paper published in their proceedings (more on this, further down the page.)

In other words, they did not follow the usual procedure of: alerting first the developers of the software of potential or actual serious vulnerabilities they had discovered in it, and then leave that for the developer’s to take care of. A “proof of concept” could be made as well, infecting a copy of the software in question with the buggy patches, in this case a copy at UMN, not the “master” at the developers’, as this group did.

Now the Linux kernel team has rejected the UMN group’s apology:

https://arstechnica.com/gadgets/2021/04/linux-kernel-team-rejects-university-of-minnesota-researchers-apology/

As to what the UMN miscreants (or fools, or both) did, in more detail, here is an excerpt from the Ars Technica article:

“The trio’s scheme involved first finding three easy-to-fix, low-priority bugs in the Linux kernel and then fixing them—but fixing them in such a way as to complete what the UMN researchers called an “immature vulnerability”:

We employ a static-analysis tool to identify three “immature vulnerabilities” in Linux, and correspondingly detect three real minor bugs that are supposed to be fixed. The “immature vulnerabilities” are not real vulnerabilities because one condition (such as a use of a freed object) is still missing […] We construct three incorrect or incomplete minor patches to fix the three bugs. These minor patches however introduce the missing conditions of the “immature vulnerabilities.”

The three researchers would then email their Trojan-horse patches to Linux kernel maintainers to see if the maintainers detected the more serious problem the researchers had introduced in the course of fixing a minor bug. Once the maintainers responded to the submitted patch, the UMN researchers pointed out the bug introduced by their patch and offered a “proper” patch—one that did not introduce a newly exploitable condition—in its place. “

Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

3 users thanked author for this post.

klang, Charlie, Alex5723

Reply | Quote

Although these two authors didn’t introduce anything, their hypocrite commits never left the emails submitted for review, see Section VI, Intro and VI A. Ethical Considerations, they should be removed from UMN for attempting to disguise a prank as legitimate research.

They mentioned concern with taking advantage of the volunteer nature of the consumer Linux community and other “We don’t want to hurt anyone” stuff, then did it anyway.  Not sure who approved this project, if anyone, but all it generated was some one-off and largely useless graph of the success of different subterfuges in a community that already was known to be vulnerable.

“Hey Linux developers, we pranked you.”

“You spent how much of your time and wasted how much of our time “proving” something we don’t have resources to prevent?”  “Here’s your honorary Masters of the Obvious diploma.”

“BTW, last straw, your university got hit with the ban hammer.  It seriously needs something to do, maybe a nine figure grant will change our minds.”

Not sure if this or all those stupid literature searches used to develop correlations of groups of previous correlations to make nutty nonreproducible conclusions are worse.

Reply | Quote

Linux Advisory Board’s ruling : Report on University of Minnesota Breach-of-Trust Incident

Report on University of Minnesota Breach-of-Trust Incident

or

“An emergency re-review of kernel commits authored by members of the
University of Minnesota, due to the Hypocrite Commits research paper.”

May 5, 2021

Prepared by the Linux Foundation’s Technical Advisory Board…

It is a very detailed long report. I don’t think that this won’t happen again.

To avoid this friction, to prevent incidents like the one described here
from happening again, and to encourage better interaction between the two
communities in general, the TAB will be working with researchers (to be
named soon) to develop a document describing a set of best practices
for researchers to follow when working with the kernel community. This
will be a living document, maintained in the kernel documentation tree
and evolved over time as needed. Any researchers who would like to
participate in this effort are encouraged to contact the TAB to express
their interest.

1 user thanked author for this post.

OscarCP

Reply | Quote