University Banned From Contributing To Linux Kernel For Intentionally Inserting Bugs

[elatllat]

mumble ... memory safe language ... mumble

[schmidtbag]

so, lemmie put it straight: they have introduced shady patches that were accepted into the mainline, they wrote a paper about intorducing bugs into the kernel and when the truth came out, it is them who are baddies in that story?

I don't see the problem here. The mainline kernel isn't meant for experimenting - people depend on it. It doesn't matter if the patch was harmless, you should not be affecting others' limited time and stress for your research paper. They could have proven their point using something less important.

To put it in a different way, that's like writing a paper about how easy it is to spread infectious diseases in hospitals, and you prove to do so by spreading a harmless virus (yes, there is such a thing) in a major regional hospital. Even if what you did has no negative consequence to the users/customers, you deserve to get banned for experimenting on something so critical.

Even if your intentions weren't to hurt anyone, that doesn't mean you won't. You just don't screw with mission-critical products, period.

I don't know if all patches from this university should be removed, but banning them is definitely justified.

[WorBlux]

lol well there goes that university's credibility. Though looking into them, seems all they really got going for them is pumping out SJWs, so.... yeah.

I'm curious about what some of the other patches are that will be removed.

They actually have a really good apple breeding program. (Honeycrisp is out of UM)

[schmidtbag]

They actually have a really good apple breeding program. (Honeycrisp is out of UM)

Hah fair enough - those are pretty good apples.

[TemplarGR]

They should be sued. This is a serious issue. I have been a teacher in academia in the past, and i know pretty damn well that every time you want to experiment for educational purposes on any tool you are doing it in a controlled environment. You do not push changes into software that is used in the real world. There is no purpose to it, other than to cause damage for whatever reason, including financial damage and even death in extreme cases (for example what if those bugs could harm a linux kernel used in medical equipment? yeah i know, most likely caught in QA, but WHAT IF NOT CAUGHT?). You do not intentionally introduce bugs into critical software unsuspecting users will end up using.

This is disgusting

[User42]

Well, they did get detected, and the consequences is to ban people doing shit like that

The only reason they got detected is they published about it... People with more questionable motives will probably not publish about it and will go undetected. That's the point.

[User42]

I don't see the problem here. The mainline kernel isn't meant for experimenting - people depend on it. It doesn't matter if the patch was harmless, you should not be affecting others' limited time and stress for your research paper. They could have proven their point using something less important.

So you mean the point of the kernel is being exploitable and exploited? They published a first paper about how they could get "malicious" code in there. Again for the 4th time, I really think they screwed up as there are other ways of handling things nicely but if anything they've shown there is little to no resistance of the kernel to "malicious" code anybody who is not bragging about it (i.e. publishing about it) could easily insert and not being caught.

It's precisely because people depend on it that it is important to review the review process, study it and improve it. If backdoors are revealed a couple times in the kernel, those people depending on it won't for long. It's just like saying "let's not try to break AES because people depend on it".

[TemplarGR]

The only reason they got detected is they published about it... People with more questionable motives will probably not publish about it and will go undetected. That's the point.

Sooner or later, the bugs would be fixed, like all bugs do get fixed. It just takes time. I have not read the paper and do not know what the bugs did, if they were harmless or not, i suppose the reason they weren't caught earlier was because they were harmless. If they had introduced something more destructive it would have been easily caught.

Still, what they did was wrong. It is a matter of principle.

[User42]

There is no purpose to it, other than to cause damage for whatever reason, including financial damage and even death in extreme cases (for example what if those bugs could harm a linux kernel used in medical equipment?

And what if "bad" people are introducing the same kind of code in the kernel, without publishing it but instead ransoming hospital? What if there were ways to improve code review and QA to avoid this kind of troubles in the first place? Again (5th time), not saying those researchers did not screw up in this specific instance. But seeing not point is certainly going a bit too far.

[User42]

Sooner or later, the bugs would be fixed, like all bugs do get fixed. It just takes time. I have not read the paper and do not know what the bugs did, if they were harmless or not, i suppose the reason they weren't caught earlier was because they were harmless. If they had introduced something more destructive it would have been easily caught.

Still, what they did was wrong. It is a matter of principle.

By all mean, read!

https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf

What you say makes sense and is even quantified with latency period, catch rate, etc. Look at figure 1... Use after free bug, 42% chance of being spotted during review. Would stay unfixed in the kernel 5 years on average. Wouldn't it be great to increase the likelihood of that thing being spotted on day 1 hopefully or at least within months, not years after release? If you don't know where the problem is, how prevalent it is, how it gets through review and what impact it has on the code, how can you "fix" it in general?