University of Minnesota researchers attempts to add vulnerability patches to the Linux Kernel. Get caught and officially banned from future patches

https://lore.kernel.org/linux-nfs/YH+zwQgBBGUJdiVK@unreal/

Researchers from the US University of Minnesota were doing a research paper about the ability to submit patches to open source projects that contain hidden security vulnerabilities in order to scientifically measure the probability of such patches being accepted and merged. Which could make the open source projects vulnerable to various attacks.

They used the Linux kernel as one of their main experiments, due to its well-known reputation and adaptation around the world.

AKA. Task failed successfully.

7 Likes

No idea how they got ethical approval for that. Research subjects are supposed to opt in to being part of research. :confused:

4 Likes

No idea either. Good thing I rejected them in favor or Michigan XD.

2 Likes

Sounds about right. A whole bunch of a complete non-sense happening in Minnesota right now, so this doesn’t surprise me either. I think the cold is driving them completely mad.

I guess the world better take us Linux nerds a whisker more seriously.

Edit, on the University’s main page. Some sort of irony here:

4 Likes

Only failed in this most recent attempt since they already successfully introduced other patches that were malicious.

I believe they’re scraping and reverting all commits, even those already in the stable tree.

Yes, thankfully it’s already a wip

IRB probably misunderstood the experiment, a lot of CS stuff is exempt as there’s no human impact. And on the surface they’re dealing with code, not people so, probably got the rubber stamp seal of approval.

1 Like

that exactly what they are doing
https://lore.kernel.org/linux-nfs/YIAtwtOpy%2FemQWr2@kroah.com/

Sending deliberately malicious commits to an open-source project has obvious ethical issues from a number of perspectives:

  1. Institutional reputation;
  2. Impacting the time and efforts of other people;
  3. Compromising the security of systems;
  4. Long-lasting potential impact of approved malicious commits being used for ongoing malicious activities.

These are just some that come to mind immediately, and without looking at a specific ethics approval process.

8 Likes

You just chopped out three words from my post dude, I wasn’t defending them, I was saying the IRB probably has no idea what they were dealing with and it was a mistake this thing got approved without consent of the people involved.

They saw a project related to code, they’re probably not experts and they were like “Cool, project about inserting potentially malicious code into an app, sounds like a security paper to me. No people, EXEMPT!!”

Project never should have gotten through IRB approval.

1 Like

Appalling! The list of UofMn commits is massive. Some bogus commits had been already fixed, some are too tangled to just revert and quite a few probably fixed real problems. Too bad kernel-org can’t invoice UofMn for all the hours wasted to review and purge suspect commits.

A couple of nation states are probably a little cranky since they make use of the kernel. Don’t be surprised if there is a future story about a sophisticated hack of UofMn. Researchers need to be a little more aware of the consequences of their research - pursued “in the name of Science.”

2 Likes

Yeah - I didn’t mean to look like I was disagreeing, I just meant to reinforce my original point about there being some pretty obvious issues that should have been caught. Either their IRB doesn’t know what they’re doing, or the researchers misrepresented the research.

It wouldn’t surprise me if the research was funded by some “interesting” funding bodies.

4 Likes

Gotcha. Gotta love text communication :wink:

1 Like

Research funded by Microsoft?

1 Like

Great that it was stopped. Who knows how many projects they’ve done this to already; they’re submitting malicious patches to projects used by millions, perhaps billions of people (in the case of the Linux kernel, because of Android and ChromeOS + servers). Imagine if it was merged into master, and before finishing their research paper and reverting their commit, someone exploited it and brought down all these systems? All someone has to do is be tired or drunk, look at the code, press some merge button, and there are at least a couple thousand systems that track the latest git snapshot.

1 Like

Given how simple it seems to be to submit malitious code, you’d assume there are some strong policies in place for evaluating a PR to the linux kernel. I think this kind of incidents help strengthen these policies

3 Likes

Interesting take, thanks for sharing

1 Like

Panky panky. They have been baaaaad boys

1 Like