How To Get A University Banned From The Linux Kernel

[@GabrielTobing]

The ban was fair and they made a good example of what happens to those that abuse a community.

[@Calajese]

"What even could go wrong?" Said the professor before everything went wrong

[@juanromanlopez4959]

Best last final words.

[@101Rouge]

Isn't a key part of white hat hacking that the organisation knowingly consents to the attack? The university's approval doesn't mean anything if there was no communication with the linux community about doing such an attack.

[@BrodieRobertson]

In this case you can't allow for everyone to be in on it, but a lead maintainer should have been informed

[@MrClassicmetal]

Exactly, a signed paper is what keeps the tester out of prison.

[@emenesu]

@@MrClassicmetal Prison lmaoooo

[@felipewerner6670]

@@emenesu you have any idea how much financial damage this can have done to all people and institutions that use linux? i bet not as your brain probabilly is on windows bsod

[@Argosh]

@Emenesu in actual reality, yes. In the past 15 years a torrent of new laws have made it increasingly difficult for security researchers to find legal paths for their work. What they did here would definitely violate laws and allow for sentencing probably on probation.

[@armynyus9123]

Sad that happened after they striked Linus for his choice of words 2 years ago or so. Would have been fun to read his unfiltered 5 cents about the issue :-)

[@RobertPrue]

Having sat on my university Institutional Review Board in the past, I would have to question this research being classified as not human subjects research. If the researchers were trying to get something past a group of people, then humans are involved, even though you are not collecting identifiable information about people, the research involved the high probability of harm being done to human being. I would think slipping bugs past someone, not only annoys and angers (harm), but also wastes their time in repairing the damage (harm), it can harm the reputation of the kernel volunteers, I think the list could go on. The board of the Linux kernel should report this to the UMN IRB.

[@matthewweber4162]

There are a ton of ethics that come into play when you're doing penetration testing, which seems like what they're doing on the most basic level. It feels like they didn't seem to care at all about those ethics.

[@BrodieRobertson]

Due to the nature of the experiement you can't let everyone in on what's going on but a lead maintainer should be aware of it.

[@Argosh]

@@BrodieRobertson no. This is the worst kind of social experiment to do. In the best case you waste everyones time. In the worst case you point your finger at individuals. This is social engineering. It's not play hacking. It's hacking.

[@R5on11c]

This is like a nurse switching out new born in a hospital and then telling the parents "Ayy lmao, it was just a test. You can still trust me tho". The ban was fair. Not irredeemable, but close.

[@rengaret]

This is unacceptable, just imagine that wants to test the safety of your car, they broke the window steal your radio and then tell you they did just research. What really shows up, it's starting to be a common way to conduct paper nowadays. It terrifies me.

[@YeOldeTraveller]

The review board was dead wrong. This is clearly human research on the means of using social engineering to introduce vulnerabilities into Linux. They were specifically using the trust inherent in the process as their vector.

[@paulbishop2198]

A ban is not only appropriate but necessary. And that ban should be permanent. Nothing would be gained by showing tolerance for deceit and inviting further exploitation. This isn't about money or rules for their own sake. This is not even directly political. It is simply not practical to tolerate patterns of behavior that puts so much effort into dire t threat of being ruined. And only actions and reactions make a difference. This was not an excusable mistake and an institution capable of such insanity cannot be expected to behave differently in the future. The should cost U of M. And those employed there who allied this study to happen need to be demoted and disempowered.

[@NewCurryofthepast]

I ban contributors from my projects for lesser offenses. If you commit code that actively makes the project worse even unintentionally, your time and effort isn't desired, bye. The maintainers are entirely within their rights heck the extent of the social engineering damage done was higher than the initial reports suggested. Mind I'm just some small nobody on the internet and the Linux kernel is of foundational importance to the modern tech and IT industry. As many other commenters pointed out it was a complete bait and switch, then giving the fake South Park "I'm sowwy." excuse. Heck this isn't the first time the incompetents from Minnesota caused them trouble.

[@uuu12343]

Looking back, this research is not just a Computer Science research paper, it became straight up an Ethical Hacking situation disguised as a research. The worst part is when they didnt even let the Linux maintainers know they were gonna do so What a disaster lmao

[@Argosh]

Unethical hacking... This isn't even grey hat territory anymore. This is a social engineering attack against the Linux kernel.

[@AnzanHoshinRoshi]

Thank you, Brodie. Good coverage. Greg, once more, has acted clearly and promptly. I am disgusted by UMI's conduct.

[@TrowGundam]

You know the old adage of "Trust, but Verify" seems relevant here. Ya, you can trust people that don't have a history of malicious action or appear to be from a reputable source, but that is no reason to not VERIFY they are so.

[@Artoooooor]

I hope students of that university can still submit commits outside of the university emails and projects. Otherwise it's just a collective punishment - thing that is never ever justified.

[@LeMeccerino]

Jannies made the right call for once? Is it the revelation and why am I still here?

[@Speykious]

No joke this is the most complete video I've found on the subject. Thank you :)

[@BrodieRobertson]

I could just give my hot take and assume that everyone watching knows about the situation but I've noticed the same thing as well, not just for this but for most big news topics

[@emenesu]

@@BrodieRobertson 1 year later, still the most complete video on the subject. Thank you for your nice work!

[@Zeioth]

This content is very interesting. I would love to learn more about good practices to contribute. There are very good official docs out there. Which obviously require toughtful study. But it would be cool having youtube content as friendly introduction.

[@rabbitroy1976]

Greg lost trust in the university once they have the ok on the paper

[@vitluk]

Instead of submitting bad patches and telling that they were bad after they've been approved, breaking the trust, they should've just tried to have a direct communication set up to one of the maintainers and explain this shit in detail, giving some pointers to improving the patch submission process. They would've gotten their research without accidentally harming the project and community, would only help, and wouldn't be banned from future contributions

[@Vini-km4dh]

man everyone in these images is being so nice I can't even believe this is the internet, and TWITTER of all places.

[@sebastianucero7535]

This black mark can't be removed. The University allowed this behavior. It's a demostration of a lack of morality from the authorities. The path taken is no only correct but necessary. Great video.

[@SoundToxin]

It's a shame the U of M did this. They seemed pretty reputable before. They were the birth place of the gopher protocol.

[@RedFenceAnime]

I've been trying to justify this in my head, but I don't think I can. Everyone can submit a patch. So that opens them up for this sort of attack. What if the email of someone trusted gets compromised? A malicious actor won't ask for permission. (this is the worst part) I think I'd possibly be ok with this if it was one or two, but not all 3 of these: And a umn email adres and pretending to fix while breaking and not notifying anyone. Sure it wastes time, but we don't live in a perfect world. I'm sure everyone would love not having to spend on any security. The resources used building barriers are also needed elsewhere, but I don't think we can live without them.

[@megamanstarforce4315]

I completely agree. The only complaint I have with the researchers is that they should have put controls in place to ensure these patches did not get through AND they should have notified one of the Linux maintainers beforehand that this was taking place so that they know which patches they would need to remove afterwards.

[@billeterk]

I’d say the response is sensible even disregarding any emotions. At least if you look at it from a game theory point of view :-). Generally I prefer the idea of tit for tat behaviour, which can be effective, but the difference in costs and payoffs for both parties here point to stricter measures.

[@0x007A]

This is part of security research whether GKH accepts reality. The contributors notified the KML and patch reviewer not to apply the patches. This experiment proves the Linux kernel maintenance process is flawed. The maintainer team needs security reviewers as part of their team.

[@BrodieRobertson]

I'll agree that the maintenance process is flawed, they should have been assuming that everyone comitting is a bad actor from the start.

[@0x007A]

@@BrodieRobertson the old adage 'trust but verify' comes to mind.

[@Luftbubblan]

Theres nothing that says that people in power positions cant change side. Security should be tight internal and external. If this whole situation was right or not im not going to comment on but it should have opened some eyes.

[@thaddaeusmarkle1665]

wow...just wow.

[@AdamFJH]

This video doesn't explain how then patch made it through even though greg was againts it. The ban is fair but it doesn't show code review process has issues and I need to know what those issues are and are they fixed. The patch should have never made if through after Greg pointed out how suspicious they were.

[@danieltm2]

Is this human research? No, we studied Linux maintainers

[@Neucher]

They should be banned until they make a large donation

[@derekschmidt6798]

They should stay banned period, or at least until they fire all staff related to the research.

[@BrodieRobertson]

From what I understand there was one staff member directly related and the of the team was graduate students

[@derekschmidt6798]

@@BrodieRobertson they should fire that staff member and the members of the board that reviewed this and approved it

[@walkergoff3127]

Whoever pays the maintainers should hire a legal team and not resort to responses that penalize students.

[@shib5267]

nah fuck em

[@dougtilaran3496]

PLM. Penguin Lives Matter !

[@nonetrix3066]

If they are this bad at checking code maybe they should check every commit what the did wasn't pog but I think it really proved something

[@BrodieRobertson]

They should never have assumed that everyone is trying to help

[@nonetrix3066]

@@BrodieRobertson agreed

[@aeroscience9834]

If they were indeed pointing out that the patches were flawed after they were approved, but before they were merged, than I don't think they did anything egregiously wrong here. I mean, yes they could have warned some of the maintainers to make it more ethical, and yes some time was wasted which is unfortunate. But In a way, is it not a good thing to keep the linux program on its toes and more security conscience? As there is far worse out there that may want to backdoor the Linux kernel.

[@BrodieRobertson]

The problem with that is it justifies everyone submitting buggy patches to waste the maintainers time

[@0x007A]

@@BrodieRobertson no it does not justify submitting potentiallty malicious patches. Software security research is a necessary activity and many potential /real exploits have been found and patched by security researchers. In this case, the UMN research team notified the kernel maintainer(s) not to apply the patch to the stable release branch as soon as the team received word that the patch was approved for inclusion and would subsequently be pushed to the stable branch at some point.

[@BrodieRobertson]

@@0x007A Creating a vulnerability to then go and fix it isn't the same thing as finding one and fixing it

[@0x007A]

@@BrodieRobertson they leveraged an existing flaw by creating a trigger for it. They do not create a new flaw in the kernel code; it is a pre-existing condition.

[@firstlast-tf3fq]

Whether the kernel devs appreciate it or not... It's perfectly valid research.

[@firstlast-tf3fq]

@@jocm99 how else are you going to see how difficult it is to get a poison commit into the Linux kernel without trying to do it? As for laws, I doubt any were broken. As for safety, I doubt the researchers would have let it get released

[@sean_r]

Not really, no, this is pretty clearly unethical. Do you expect the kernel maintainers to just be okay with them sabotaging the kernel millions of people use after hearing "it's just a test, bro"?

[@firstlast-tf3fq]

@@sean_r well… yeah actually, they shouldn’t have failed the test