A lot of people seem to consider this meaningless and a waste of time. If we disregard the the problems with the patches reaching stable branches for a second (which clearly is problematic), what is the difference between this and companies conducting red team exercises? It seems to me a potentially real and dangerous attack vector has been put under the spotlight here. Increasing awareness around this can't be all bad, particularly in a time where state sponsored cyber attacks are getting ever more severe.
“They introduce kernel bugs on purpose”
211–220 of 1001 posts
Re: “They introduce kernel bugs on purpose”
#212From https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N... , > A lot of these have already reached the stable trees. If the researchers were trying to prove that it is possible to get malicious patches into the kernel, it seems like they succeeded -- at least for an (insignificant?) period of time.
I tangentially followed the debacle unfold for a while and this particular thread now has lead to heated debates on some IRC channels I'm on. While it is maybe "scientifically interesting", intentionally introducing bugs into Linux that could potentially make it into production systems while work on this paper is going on, could IMO be described as utterly reckless at best . Two messages down in the same thread, it m…
If they're public IRC channels, do you mind mentioning them here? I'm trying to find the remnant. :)
Re: “They introduce kernel bugs on purpose”
#213The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pak…
If the IRB is any good the professor doesn't get that. Universities are publish or perish, and the IRB should force the withdrawal of all papers they submitted. This is might be enough to fire the professor with cause - including remove any tenure protection they might have - which means they get a bad reference.
I hope we hear from the IRB in about a year stating exactly what happened. Real investigations of bad conduct should take time to complete correctly and I want them to do their job correctly so I'll give them that time. (there is the possibility that these are good faith patches and someone in the linux community just hates this person - seems unlikely but until a proper independent investigation is done I'll leave that open.)
Re: “They introduce kernel bugs on purpose”
#214From https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N... , > A lot of these have already reached the stable trees. If the researchers were trying to prove that it is possible to get malicious patches into the kernel, it seems like they succeeded -- at least for an (insignificant?) period of time.
It may be unethical from an academic perspective, but I like that they did this. It shows there is a problem with the review process if it is not catching 100% of this garbage. Actual malicious actors are certainly already doing worse and maybe succeeding. In a roundabout way, this researcher has achieved their goal, and I hope they publish their results. Certainly more meaningful than most of the drivel in the acade…
> It shows there is a problem with the review process if it is not catching 100% of this garbage.
It shows nothing of the sort. No review process is 100% foolproof, and opensource means that everything can be audited if it is important to you.
The other option is closed source everything and I can guarentee that review processes let stuff through, even if its only "to meet deadlines" and you will unlikely be able to audit it.
Re: “They introduce kernel bugs on purpose”
#215Earlier quoted context omitted.
> I think all patches have come from people currently being advised by Kangjie Liu[3] or Liu himself dating back to Dec 2018 New plan: Show up at Liu's house with a lock picking kit while he's away at work, pick the front door and open it, but don't enter. Send him a photo, "hey, just testing, bro! Legitimate security research!"
This is funny, but not at all a good analogy. There's obviously not remotely as much public interest or value in testing the security of this professor's private home to justify invading his privacy for the public interest. On the other hand, if he kept dangerous things at home (say, BSL-4 material), then his house would need 24/7 security and you'd probably be able to justify testing it regularly for the public's sa…
It wasn't intended to be serious. But on the other hand, he has now quite openly and publicly declared himself to be part of a group of people who mess around with security related things as a "test".
He shouldn't be surprised if it has some unexpected consequences to his own personal security, like some unknown third parties porting away his phone number(s) as a social engineering test, pen testing his office, or similar.
Re: “They introduce kernel bugs on purpose”
#216Later down thread from Greg K-H: > Because of this, I will now have to ban all future contributions from your University. Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures. In t…
> Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. That's the university's problem to fix.
What's the recourse for them though? Just beg to have the decision reversed?
Re: “They introduce kernel bugs on purpose”
#217Earlier quoted context omitted.
> The thread then gets down to business and starts coordinating revert patches for everything committed by University of Minnesota email addresses. What's preventing those bad actors from not using a UMN email address?
Literally nothing. Instead of actual actions to improve the process it's only feel-good actions without any actual benefit to the kernel's security.
The point is to make it very obviously not worth it to conduct this kind of unethical research. I don't think UMN is going to be eager to have this kind of attention again. People could always submit bogus patches from random email addresses - this removes the ability to do it under the auspices of a university.
Re: “They introduce kernel bugs on purpose”
#218Uhhh, I just read the paper, I stopped reading when I read what I pasted below. You attempt to introduce severe security bugs into the kernel and this is your solution?
To mitigate the risks, we make several suggestions. First, OSS projects would be suggested to update the code of conduct by adding a code like "By submitting the patch, I agree to not intend to introduce bugs."
Re: “They introduce kernel bugs on purpose”
#219Earlier quoted context omitted.
> The thread then gets down to business and starts coordinating revert patches for everything committed by University of Minnesota email addresses. What's preventing those bad actors from not using a UMN email address?
Literally nothing. Instead of actual actions to improve the process it's only feel-good actions without any actual benefit to the kernel's security.
You keep posting all over this discussion about how the Linux maintainers are making a poor choice and shooting the messenger.
What would you like them to do instead or in addition to this?
Re: “They introduce kernel bugs on purpose”
#220They just wasted the community's time. No wonder Linus Trovalds goes batshit crazy on these kind of people!