Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

Post reply on HN
Print view View original

161–170 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#161

Post by md_ »

st_goliath wrote: post #24
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.

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…

I'm confused. The cited paper contains this prominent section:

Ensuring the safety of the experiment. In the experiment, we aim to demonstrate the practicality of stealthily introducing vulnerabilities through hypocrite commits. Our goal is not to introduce vulnerabilities to harm OSS. Therefore, we safely conduct the experiment to make sure that the introduced UAF bugs will not be merged into the actual Linux code. In addition to the minor patches that introduce UAF conditions, we also prepare the correct patches for fixing the minor issues. We send the minor patches to the Linux community through email to seek their feedback. Fortunately, there is a time window between the confirmation of a patch and the merging of the patch. Once a maintainer confirmed our patches, e.g., an email reply indicating “looks good”, we immediately notify the maintainers of the introduced UAF and request them to not go ahead to apply the patch.

Are you saying that despite this, these malicious commits made it to production?

Taking the authors at their word, it seems like the biggest ethical consideration here is that of potentially wasting the time of commit reviewers—which isn't nothing by any stretch, but is a far cry from introducing bugs in production.

Are the authors lying?

Re: “They introduce kernel bugs on purpose”

#163

Post by dmitryminkovsky »

jnxx wrote: post #141
toxik wrote: post #16

The problem here is really that they’re wasting time of the maintainers without their approval. Any ethics board would require prior consent to this. It wouldn’t even be hard to do.

> The problem here is really that they’re wasting time of the maintainers without their approval. Not only that, but they are also doing experiments on a community of people which is against their interest and also could be harmful by creating mistrust. Trust is a big issue, without it it is almost impossible for people to work meaningfully together.

Yeah this actually seems more like sociological research except since it’s in the comp sci department the investigators don’t seem to be trained in acceptable (and legal) standards of conducting such research on human subjects. You definitely need prior consent when doing this sort of thing. Ideally this would be escalated to a research ethics committee at UMN because these researchers need to be trained in acceptable practices when dealing with human subjects. So to me it makes sense the subjects “opted out” and escalated to the university.

Re: “They introduce kernel bugs on purpose”

#164

Post by ansible »

I still don't get the point of this "research".

You're just testing the review ability of particular Linux kernel maintainers at a particular point in time. How does that generalize to the extent needed for it to be valid research on open source software development in general?

You would need to run this "experiment" hundreds or thousands of times across most major open source projects.

Re: “They introduce kernel bugs on purpose”

#165

Post by jnxx »

tester34 wrote: post #63

Researcher(s) shows that it's relatively not hard to introduce bugs in kernel HN: let's hate researcher(s) instead of process Wow. Assume good faith, I guess?

It is not hard to point a gun at someone's head.

But let's assume your girlfriend points an (unknown to you) empty gun at your head, because she wants to know how you will react. What do you think is the appropriate reaction?

Re: “They introduce kernel bugs on purpose”

#166

Post by noxer »

_vufv wrote: post #128
noxer wrote: post #86

Someone does voluntary work and people think that gives them some ethical privilege to be asked before someone puts their work to the test? Sure it would be nice to ask but at the same time it renders the testing useless. They wanted to see how the review goes if they aren't aware that someone is testing them. You cant do this with consent. The wasting time argument is nonsense too its not like they did this thousand…

> They wanted to see how the review goes if they aren't aware that someone is testing them. You cant do this with consent. Ridiculous. Does the same apply to pentesting a bank or a government agency. If you wanted to pentest these of course you'd get approval from an executive that has power to sanction this. Why would Linux development be an exception? Just ask GKH or someone to allow you to do this.

Ridiculous comparison indeed. There was no pen testing going on. Submitted code does not attack or harming any running system and whoever uses is does so completely voluntary. I dont need anyone's approval for that. The license already states that I'm not liable in any way for what you do with it.

Re: “They introduce kernel bugs on purpose”

#167

Post by splithalf »

kstenerud wrote: post #3
kdbg wrote: post #2

I don't think there have been any recent comments from anyone at U.Mn. So, back when the original research (happened last year) the following clarification was offered by Qiushi Wu and Kangjie Lu which atleast paints their research in somewhat better light: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... That said the current incident seems to have gone beyond the limits of that one and is a new incid…

From their explanation: (3). We send the incorrect minor patches to the Linux community through email to seek their feedback. (4). Once any maintainer of the community responds to the email, indicating “looks good”, we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all the three…

There is sometimes an exception for things like interviews when n is only a couple of people. This was clearly unethical and it’s certain that at least some of those involved knew that. It’s common knowledge universities.

Re: “They introduce kernel bugs on purpose”

#168

Post by hjalle »

GoblinSlayer wrote: post #154
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…

Forking the kernel should be sufficient for research.

Not if the research involves the reviewing aspects of open source projects.

Re: “They introduce kernel bugs on purpose”

#169

Post by tapland »

Cthulhu_ wrote: post #157
walrus01 wrote: post #147

Earlier 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!"

If they wanted to do security research, they could have done so in the form of asking the reviewers to help; send them a patch and ask 'Is this something you would accept?', instead of intentionally sending malicious commits and causing static on the commit tree and mailing lists.

Dd they keep track of and submit a list of additions to revert after they managed to get it added?

From the looks of it they didn't even when it was heading out to stable releases?

That's just using the project with no interest in not causing issues.

Post reply on HN