“They introduce kernel bugs on purpose” • Hacker News Board

Re: “They introduce kernel bugs on purpose”

#131

Post by robertlagrant » Wed, Apr 21, 2021, 11:50 AM UTC

throwawaybbq1 wrote: post #65

jedimastert wrote: post #37

Out of curiosity, what would be an actually good way to poke at the pipeline like this? Just ask if they'd OK a patch w/o actually submitting it? A survey?

This is a good question. You would recruit actual maintainers, [edit: or whoever is your intended subject pool] (who would provide consent, perhaps be compensated for their time). You could then give them a series of patches to approve (some being bug free and others having vulnerabilities). [edit: specifying the population of a study is pretty important. Getting random students from the University to approve your se…

> This took 1 min of thinking btw.

QFT.

Re: “They introduce kernel bugs on purpose”

#132

Post by rlpb » Wed, Apr 21, 2021, 11:50 AM UTC

cblconfederate wrote: post #69

I guess someone had to do this unethical experiment, but otoh, what is the value here? There's a high chance someone would later find these "intentional bugs" , it's how open source works anyway. They just proved that OSS is not military-grade , but nobody thought so anyway

> They just proved that OSS is not military-grade...

As if there is some other software that is "military-grade" by the same measure? What definition are you using for that term, anyway?

Re: “They introduce kernel bugs on purpose”

#133

Post by causality0 » Wed, Apr 21, 2021, 11:54 AM UTC

I respectfully ask you to cease and desist from making wild accusations that are bordering on slander.

Responding properly to that statement would require someone to step out of the HN community guidelines.

Re: “They introduce kernel bugs on purpose”

#134

Post by DetroitThrow » Wed, Apr 21, 2021, 11:55 AM UTC

hn8788 wrote: post #117

ilammy wrote: post #98

So many comments here refrain, “They should have asked for consent first”. But would not that be detrimental to the research subject? Specifically, stealthily introducing security vulnerabilities. How should a consent request look to preserve the surprise factor? A university approaches you and says, “Would it be okay for us to submit some patches with vulnerabilities for review, and you try and guess which ones are…

It could have been done similar to how typosquatting research was done for ruby and python packages. The owners of the package repositories were contacted, and the researchers waited for approval before starting. I wasn't a fan of that experiment either for other reasons, but hiding it from everyone isn't the only option. Also, "you wouldn't have allowed me to experiment on you if I'd asked first" is a pretty disgust…

"you wouldn't have allowed me to experiment on you if I'd asked first"

I'm shocked the researchers thought this wasn't textbook a violation of research ethics - we talk about the effects of the Tuskegee Study on the perception of the greater scientific community today.

This is a smaller transgression that hasn't resulted in deaths, but when it's not difficult to have researched ethically AND we now spend the time to educate on the importance of ethics, it's perhaps more frustrating.

Re: “They introduce kernel bugs on purpose”

#135

Post by moron4hire » Wed, Apr 21, 2021, 11:56 AM UTC

It's funny. When someone like RMS or ESR or (formerly) Torvalds is "disrespectful" to open source maintainers, this is called "tough love", but when someone else does it, it's screamed about like it's some kind of high crime, with calls to permanently cancel access for all people even loosely related to the original offender.

Re: “They introduce kernel bugs on purpose”

#136

Post by wang_li » Wed, Apr 21, 2021, 11:58 AM UTC

gnfargbl wrote: post #21

From 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.

There’s no research going on here. Everyone knows buggy patches can get into a project. Submitting intentionally bad patches adds nothing beyond grandstanding. They could perform analysis of review/acceptance by looking at past patches that introduced bugs without being the bad actors that they apparently are.

From FOSDEM 2014, NSA operation ORCHESTRA annual status report. It’s pretty entertaining and illustrates that this is nothing new.

https://archive.fosdem.org/2014/schedule/event/nsa_operation... https://www.youtube.com/watch?v=3jQoAYRKqhg

Re: “They introduce kernel bugs on purpose”

#137

Post by ajuc » Wed, Apr 21, 2021, 12:00 PM UTC

jedimastert wrote: post #37

Out of curiosity, what would be an actually good way to poke at the pipeline like this? Just ask if they'd OK a patch w/o actually submitting it? A survey?

Ask about this upfront, get consent, wait rand()*365 days and do the same thing they did. Inform people immediately after it got accepted.

Re: “They introduce kernel bugs on purpose”

#138

Post by svarog-run » Wed, Apr 21, 2021, 12:00 PM UTC

I feel like q lot of people here did not interpret this correctly.

As far as it's known, garbage code was not introduced into kernel.It was caught in the review process literally on the same day.

However, there has been merged code from the same people, which is not necessarily vulnerable. As a precaution the older commits are also being reverted, as these people have been identified as bad actors

Re: “They introduce kernel bugs on purpose”

#139

Post by ajuc » Wed, Apr 21, 2021, 12:01 PM UTC

moron4hire wrote: post #135

It's funny. When someone like RMS or ESR or (formerly) Torvalds is "disrespectful" to open source maintainers, this is called "tough love", but when someone else does it, it's screamed about like it's some kind of high crime, with calls to permanently cancel access for all people even loosely related to the original offender.

https://www.youtube.com/watch?v=I7Umw70Yulw

Re: “They introduce kernel bugs on purpose”

#140

Post by [deleted] » Wed, Apr 21, 2021, 12:01 PM UTC

jnxx wrote: post #122

ENOTTY wrote: post #22

Later 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.

[deleted]