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

121–130 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#121

Post by mratsim »

jeroenhd wrote: post #90
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?

The concept of the research is quite good. The way this research was carried out, is downright unethical. By submitting their bad code to the actual Linux mailing list, they have made Linux kernel developers part of their research without their knowledge or consent. Some of this vandalism has made it down into the Linux kernel already. These researchers have sabotaged other people's software for their personal gain,…

To provide some parallel on how the research was carried about:

I see it as similar to

- allowing recording of people without their consent (or warrant),

- experimenting on PTSD by inducing PTSD without people consent,

- or medical experimentation without the subject consent.

And the arguments about not having anyone know:

Try to introduce yourself in the White House and when you get caught tell them "I was just testing your security procedures".

Re: “They introduce kernel bugs on purpose”

#122

Post by jnxx »

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.

Re: “They introduce kernel bugs on purpose”

#123

Post by enneff »

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…

Well, yeah, but the priority here shouldn't be to allow the researchers to do their work. If they can't do their research ethically then they just can't do it; too bad for them.

Re: “They introduce kernel bugs on purpose”

#124

Post by DetroitThrow »

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…

>So many comments here refrain, “They should have asked for consent first”.

The Linux kernel is a very large space with many maintainers. It would be possible to reach out to the leadership of the project to ask for approval without notifying maintainers and have the leadership announce "Hey, we're going to start allowing experiments on the contribution process, please let us know if you'd like to opt out", or at least work towards creating such a process to allow experiments on maintainers/commit approval process while also under the overall expectation that experiments may happen but that *they will be reverted before they reach stable trees*.

The way they did their work could impact more than just the maintainers and affect the reputation of the Linux project, and to me it's very hard to see how it couldn't have been done in a way that meets standards for ethical research.

Re: “They introduce kernel bugs on purpose”

#125

Post by bargle0 »

EamonnMR wrote: post #92
devit wrote: post #61

The project is interesting, but how can they be so dumb as to post these patches under an @umn.edu address instead of using a new pseudonymous identity for each patch?!? I mean, sneakily introducing vulnerabilities obviously only works if you don't start your messages by announcing you are one of the guys known to be trying to do so...

That's kind of the rub. They used a university email to exploit the trust afforded to them as academics and then violated that trust. As a result that trust was revoked. If they want to submit future patches they'll need to do it with random email addresses and will be subject to the scrutiny afforded random email addresses.

Why should an academic institution be afforded any extra trust in the first place?

Re: “They introduce kernel bugs on purpose”

#126

Post by Werewolf255 »

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…

Yeah we get to hold people who are claiming to act in good faith to a higher standard than active malicious attackers. Their actions do not comport with ethical research practices.

Re: “They introduce kernel bugs on purpose”

#127

Post by TeMPOraL »

henearkr wrote: post #38
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…

Not a big loss: these professors likely hate open source. [edit: they do not. See child comments.] They are conducting research to demonstrate that it is easy to introduce bugs in open source... (whereas we know that the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards) [removed this ranting that does not apply since they are contributing a lot to the kernel in g…

> Not a big loss: these professors likely hate open source.

> They are conducting research to demonstrate that it is easy to introduce bugs in open source...

That's a very dangerous thought pattern. "They try to find flaws in a thing I find precious, therefore they must hate that thing." No, they may just as well be trying to identify flaws to make them visible and therefore easier to fix. Sunlight being the best disinfectant, and all that.

(Conversely, people trying to destroy open source would not publicly identify themselves as researchers and reveal what they're doing.)

> whereas we know that the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards

How do we know that? We know things by regularly testing them. That's literally what this research is - checking how likely it is that intentional vulnerabilities are caught during review process.

Re: “They introduce kernel bugs on purpose”

#128

Post by _vufv »

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.

Re: “They introduce kernel bugs on purpose”

#129

Post by jnxx »

bionhoward wrote: post #53
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…

seems extreme. one unethical researcher blocks work for others just because they happen to work at the same employer? they might not even know the author of the paper...

Well, shit happens. Imaging doctors working in organ transplants, and one of them damages trust of people by selling access to organs to rich patients. Of course that damages the field for everyone. And to deal with such issues, doctors have some ethics code, and in many countries associations which will sanction bad eggs. Perhaps scientists need something like that, too?

Re: “They introduce kernel bugs on purpose”

#130

Post by s_dev »

testplzignore wrote: post #58
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.

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

What review process catches 100% garbage? It's a mechanism to catch 99% of garbage -- otherwise Linux kernel would have no bugs.

Post reply on HN