The Linux kernel is currently the subject of some University "research" that apparently seeks to prove that "Open Source" software is inherently insecure.

The "researchers" attempt to demonstrate this by submitting malicious kernel patches to the Linux Kernel Mailing List. As these submissions come from persons attached to a (at least previously) respected institution, many such patches have been accepted.

Greg Kroah-Hartman called them out in this LKML thread, and all the patches from these submitters are now being summarily reverted.

Also, it seems the entire university will be banned from participating in Linux kernel development from now on.

Penetration testing and fooling people is a very very serious topic.
They probably should have done this differently:
a) identify a testified organization preferably observed by lawyers in a serious country
b) inform the linux org lawyers of the try to penetrate linux forums: the target is not to fool and demonstrate they are idiots but should demonstrate this is for making them better
c) make the penetration
d) show to them the area of improvement
e) make it public afterward
The university have not followed the steps (or similar serious steps?) and would show to me only I am a fool?
I would throw them out and ban them.. (I want to improve.. not that people show to me I am a fool).

That's rather worrying - I would have expected code reviews on all submissions, irrespective of their email address!

Of course, and the intentionally introduced bugs were eventually caught. But one can see why a patch from a known CS graduate at a US university might be subject to a bit less scrutiny than a patch that appears out of the blue from "random_dude@gmail.com".

I believe the main issue is that the UoM project is being conducted in a way that violates the most basic ethical standards. In the course of their "research", they actually introduced serious vulnerabilities in the Linux kernel.

Had they followed the practices outlined in this paper, at least the commits wouldn't actually have been applied. But they didn't.

For their next project, perhaps they should write a paper on "the Feasibility of Stealthily Introducing Vulnerabilities in Closed-Source software via malicious insiders"? Some of their students could apply for coding jobs at Microsoft, and then push carefully crafted security bugs into the Windows kernel.

One might, but I can't. No patches applied without understanding what they do.

Perhaps, if I received an expected patch from Linus Torvalds (or another core committer), I might give benefit of the doubt and apply it before seeking to comprehend it. Perhaps.



Had they followed those practices, we probably wouldn't be discussing this.

Had the maintainers applied their usual high standards and caught them all before they reached stable, we also wouldn't be discussing this.

(Unless they did apply their usual standards, and they're not as high as we would hope!)

Either way, the lapse which alarms me more is on the kernel side.


Or maybe they already are. If I worked at Microsoft I'd be having all commits from recent new hires checked by independent teams. Imagine the PR boost if they were able to say they found such an attempt before anything got through. :/

The paper also explicitly mentions FreeBSD, Firefox, and OpenSSL - let's hope their organisations are now exercising increased diligence.

The student's whiny response after having gotten caught does not help the situation. Furthermore, there seems to be a "research" paper, posted at an infamous M$ site, about trolling several big name projects with crap, deceptive code submissions. In addition to the kernel, FreeBSD, Firefox, and OpenSSL get named. So those projects also ought to go back and recheck for any University of Minnesota patches.

There are also usually ethical rules which psychological experiments such what this appears to be must adhere to most strictly. There are also similar guidelines for security research, especially penetration testing. Those also seem to have been ignored, at least at first glance. Looking at one article and at Greg's e-mail to the list, it is likely that the University of Minnesota could have been in violation.

( Edit: it seems that the list covered that : https://lore.kernel.org/linux-nfs/3B...theastern.edu/ )

It is something that is worth taking upstream. That department needs an audit for compliance with both sets of guidelines and, while the hood is up, faculty member or student ties or allegiances to M$ should be ferreted out.

+1

The most important thing to come out of this is that those patches were committed - and that highlights that code reviews are inadequate. The response, in terms of banning those involved doesn't address the problem at all.

1 members found this post helpful.

Well, no-one did that.

Have you seen the patches in question? The ones I've looked at all seem to do something pretty trivial. The vulnerability is either hidden in some other alteration you're meant to overlook, or it follows as a side effect under very specific circumstances. Like the stuff you'd find in The Underhanded C Contest back in the day.

And still they did get caught, just not right away.Do you believe the Linux developers have some incentive to keep using a bad review practice if someone were to demonstrate deficiencies in their processes?I'd like to see the practices and standards that cannot be subverted by a malicious actor under any circumstances.

I mean, it's obvious that large companies like Microsoft, Red Hat, Oracle, SAP, and IBM aren't immune to this, as vulnerabilities caused by basic programming errors like buffer overflows, wrong typecasting, and insufficient input sanitation keep turning up in their products.

I'd say the Linux kernel has a pretty decent track record compared to the industry leaders. Compared to a utopian ideal we'll never achieve they still fall far short, of course.

They should be hunted to the edge of the world...

The referenced "paper" seems to have disappeared? Any alternative link?


There's something rotten in the state of... Minnesota.

2 members found this post helpful.

While I agree that the kernel maintainers need to at least review and probably adjust how they accept patches and from whom, the kernel itself and the network of contributors is almost certainly too complex to rely on any "policy" as the filter of last resort. Malicious actors profile the policies as much as the code and the people and there is always going to be some exploitable path to be found. KUDOS to GKH for calling this one out.

I think that in such cases it is of utmost importance to call this what it is - INTENTIONAL MALICIOUS ATTEMPT TO SUBVERT software used by millions in many diverse and doubtless assorted critical applications. Stop calling it research, or penetration testing (another weasle-speak term) or anything of the sort... in ANY other realm it would be considered CRIMINAL activity and should be treated as such. The professor, so-called, behind this activity has apparently promoted this very activity in the past and definitely needs to suffer some consequences! The students involved need to be reprimanded and sent to a remedial ethics training course.

Scratch that as the page doesn't show error anymore... https://github.com/QiushiWu/QiushiWu...Insecurity.pdf

...and it has been archived as well, just in case.

In the meantime I've now read that paper...


But has there ever been committed and merged "evil" code in the history of Linux?

That is, before this...


Excerpts from the paper...

Well... then I don't understand why Greg sits there with a list as long as his arm of commits to be re-reviewed and/or reverted...


Not so sure the maintainers are entirely pleased with having to take a second view of the commit procedures, but that's probably the best outcome of this...?

But as initial asked: is there really a problem with malicious commits?

So... their research proved that they are capable of criminal behavior.

That said, it is worrying that submitted kernel patches aren't necessarily fully scrutinized.

Yes it helps to read the paper itself.

I don't believe that anyone should be criminalised for exposing what they have exposed - i.e. that code review audits need improving. Especially with regards to an important project such as Linux.