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

941–950 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#941

Post by yuliyp »

spullara wrote: post #855
rzwitserloot wrote: post #181

The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pak…

Perhaps the Linux kernel team should actively support a Red Team to do this with a notification when it would be merged into the stable branch.

What would be the point? Of course people can miss things in code review. Yet the Linux developer base and user base has decided that generally an open submission policy has benefits that outweigh the risks.

Should every city park with a "no alcohol" policy conduct red teams on whether it's possible to smuggle alcohol in? Should police departments conduct red teams to see if people can get away with speeding?

Re: “They introduce kernel bugs on purpose”

#942

Post by rossjudson »

DannyBee wrote: post #899
rzwitserloot wrote: post #181

The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pak…

Joke's on you - this was really sociology research on anger response levels of open source communities when confronted with things that look like bad faith.

WaitASecond...are you saying that this was an experiment to find out how the maintainers would react to being experimented on? ;)

Re: “They introduce kernel bugs on purpose”

#943

Post by nullc »

CS department security research is near universally not held to be in the scope of IRBs. This isn't entirely bad: the IRB process that projects are subjected to is so broken that it would be a sin to bring that mess on any other things.

But it means the regularly 'security' research does ethically questionable stuff.

IRBs exist because of legal risk. If parties harmed by unethical computer science research do not litigate (or bring criminal complaints, as applicable) the university practices will not substantially change.

Re: “They introduce kernel bugs on purpose”

#944

Post by subhrm »

whack wrote: post #784

Let me play devil's advocate here. Such pen-testing is absolutely essential to the safety of our tech ecosystem. Countries like Russia, China and USA are without a doubt, doing exactly the same thing that this UMN professor is doing. Except that instead of writing a paper about it, they are going to abuse the vulnerabilities for their own nefarious purposes. Conducting such pen-tests, and then publishing the results…

Any party caught willinging sabotaging such a prominent open source project would definitely face greater consequences than just a ban.

Re: “They introduce kernel bugs on purpose”

#945

Post by Wxc2jjJmST9XWWL »

mikewarot wrote: post #934
sida wrote: post #933

Let me play devil's advocate here though. This is absolutely necessary and shows the process in the kernel is vulnerable. Sure, this is "just" a university research project this time. And sure, this is done in bad taste. But there are legitimately malicious national actors (well, including the US govt and the various 3 letter agencies) that absolutely do this. And the national actors are likely even far more sophisti…

Let me pile on top of that and note that if Linus had listened to his elders and used a Microkernel instead of the monolith, the kernel would be small enough that this kind of thing wouldn't be happening.

You are free to use Minix or Hurd, not sure if a modern browser will even run, but if you want a microkernel so badly...

So if only Linus would have listened we would have Linux as microkernel equally feature rich and widespread? Stupid Linus /s

https://www.minix3.org/

https://www.gnu.org/software/hurd/

Re: “They introduce kernel bugs on purpose”

#946

Post by BiteCode_dev »

rzwitserloot wrote: post #181

The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pak…

The problem with such experiment is that it can be a front. If you are a big entity, gov, or whatever, and you need to insert a vulnerability in the kernel, you can start a "research project". Then you try to inject it with this pretense, and if it fails, you can always say "my bad, it was for science".

Re: “They introduce kernel bugs on purpose”

#947

Post by dawnbreez »

ltfish wrote: post #413

Some clarifications since they are unclear in the original report. - Aditya Pakki (the author who sent the new round of seemingly bogus patches) is not involved in the S&P 2021 research. This means Aditya is likely to have nothing to do with the prior round of patching attempts that led to the S&P 2021 paper. - According to the authors' clarification [1], the S&P 2021 paper did not introduce any bugs into Linux kerne…

There's only one way the kernel dev team can afford to look at this: A bad actor tried to submit malicious code to the kernel using accounts on the U of M campus. They can't afford to assume that the researchers weren't malicious, because they didn't follow the standards of security research and did not lay out rules of engagement for the pentest. Because that trust was violated, and because nobody in the research team made the effort to contact the appropriate members of the dev team (in this case, they really shoulda taken it to Torvalds), the kernel dev team can't risk taking another patch from U of M because it might have hidden vulns in it. For all we know, Aditya Pakki is a pseudonym. For all we know, the researchers broke into Aditya's email account as part of their experiment--they've already shown that they have a habit of ignoring best practices in infosec and 'forgetting' to ask permission before conducting a pentest.

Re: “They introduce kernel bugs on purpose”

#948

Post by dawnbreez »

nullc wrote: post #943

CS department security research is near universally not held to be in the scope of IRBs. This isn't entirely bad: the IRB process that projects are subjected to is so broken that it would be a sin to bring that mess on any other things. But it means the regularly 'security' research does ethically questionable stuff. IRBs exist because of legal risk. If parties harmed by unethical computer science research do not lit…

Security research has its own standards of ethics, and these researchers violated those standards.

1. You don't conduct a penetration test without permission to do so, or without rules of engagement laying out what kinds of actions and targets are permitted. The researchers did not seek permission or request RoE; they tried to ask forgiveness instead.

2. You disclose the vulnerabilities immediately to the software's developers, and wait a certain period before revealing the vulns to the public. While the researchers did immediately notify the kernel dev team in 3 cases, there's apparently another vulnerable commit that the researchers didn't mention in their paper and did not tell the kernel dev team about, which was still in the kernel as of the paper's publish date.

Apparently the IRB team that reviewed this project decided that no permission was needed because the experiment was on software, not people--even though the whole thing hinged on human code review practices. It's evident that the IRB doesn't know how infosec research should be conducted, how software is developed, or how code review works, but it's also evident that the researchers themselves either didn't know or didn't care about best practices in infosec.

Re: “They introduce kernel bugs on purpose”

#949

Post by dawnbreez »

up2isomorphism wrote: post #866

From an outsider, the main question is: does this expose an actual weakness in the Linux development model? From what I understand, this answer seems to be a "yes". Of course, it is understandable that GKH is frustrated, and if his community do not like someone pointing out this issue, it is OK too. However, one researcher does not represent the whole university, so it seems immature to vent this to other unrelated p…

The main issue is that the researchers are now untrustworthy because they conducted this experiment without permission. Essentially, the kernel dev team can no longer trust that any given patch from U of M isn't the same research team using a different email address to submit more malicious patches.
Post reply on HN