Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

691–700 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#691
post #686

Researcher sends bogus papers to journal/conference, gets them reviewed and approved, uses that to point how ridiculous the review process of the journal is => GREAT JOB, PEER REVIEW SUCKS! Researcher sends bogus patches to bazaar-style project, gets them reviewed and approved, uses that to point how ridiculous the review process of the project is => DON'T DO THAT! BAD RESEARCHER, BAD!

One potentially misleads readers of the journal, the other introduces security vulnerabilities into the world’s most popular operating system kernel.

"Misleading readers of a journal" might actually cause more damages to all of humanity (see https://en.wikipedia.org/wiki/Growth_in_a_Time_of_Debt) than inserting a security vulnerability (that is likely not even exploitable) in a driver that no one actually enables (which is likely why no one cares about reviewing patches to it, either).

Thought to be fair, it is also the case that only the most irrelevant journals are likely to accept the most bogus papers. But in both cases I see no reason not to point it out.

The two situations are much more closer than what you think. The only difference I see is in the level of bogusness.

Re: “They introduce kernel bugs on purpose”

#692
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…

Aditya's story about the new patches is that he was writing a static analysis tool and was testing it by... submitting PRs to the Linux kernel? He's either exploiting the Linux maintainers to test his new tool, or that story's bullshit. Even taking his story at face value is justification to at least ban him personally IMO.

People do this with static analysis tools all the time. It’s obnoxious but not necessarily malicious.

Re: “They introduce kernel bugs on purpose”

#693
post #639
post #626

It would be fascinating to see the ethics committee exemption. I sense there was none. Or is this kind of experiment deemed fair game? Red vs blue team kind of thing? Penetration testing. But if it was me in this situation, I'd ban them for ethics violation as well. Acting like a Evil doer means you might get caught... and punished. I found the email about cease and desist particularly bad behavior. If that student w…

I didn't read this bit: "The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. We obtained a formal IRB-exempt letter" Um. Ok.

How does an IRB usually work? Is it the same group of people reviewing all proposals for the entire university? Or are there subject-matter experts (and hopefully lawyers) tapped to review proposals in their specific domain? Applying “ethics” to a proposal is meaningless without understanding not just how they plan to implement it but how it could be implemented.

Re: “They introduce kernel bugs on purpose”

#696

Not wanting to play the devil's advocate here but though scummy, they still successfully introduced vulnerabilities to the kernel. Suppose the paper hadn't been released or an adversary had done it. How long they'll be lingering around if they're ever removed? The paper makes a case that FOSS projects shouldn't merely trust authority for security (neither the ones submitting or the ones reviewing) but utilize tools t…

Coverity found at least one:

vvv CID 1503716: Null pointer dereferences (REVERSE_INULL) vvv Null-checking "rm" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.

and tools are useful, but given the resources and the know-how of those who compete in the IOCC I think we'd have to assume they'd be able to get something through. It'd have an even higher chance of success if it could be built to target a particular hardware combination (of a desired victim) as you could make the exploit dependent on multiple parts of the code (and likely nobody would ever determine the extent, as they'd find parts of it and fix them independently).

Re: “They introduce kernel bugs on purpose”

#697
post #687

Whoa this is some heavy DC, a Chinese spy got busted trying to poison the Linux kernel. And then he came up with an excuse.

just because they chose to use Chinese names, doesnt make them less American. Are you suggesting non-Chinese Americans cant be spies?

Re: “They introduce kernel bugs on purpose”

#698

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

This is funny, but not at all a good analogy. There's obviously not remotely as much public interest or value in testing the security of this professor's private home to justify invading his privacy for the public interest. On the other hand, if he kept dangerous things at home (say, BSL-4 material), then his house would need 24/7 security and you'd probably be able to justify testing it regularly for the public's sa…

Everyone has been saying "This affects software that runs on billions of machines and could cause untold amounts of damage and even loss of human life! What were the researchers thinking?!" and I guess a follow-up thought, which is that "Maintainers for software that runs on billions of machines, where bugs could cause untold amounts of damage and even loss of human life didn't have a robust enough system to prevent this?" never occurs to anyone. I don't understand why.

Re: “They introduce kernel bugs on purpose”

#699
post #458
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…

But Kanjie Lu, Pakki’s advisor, was one of the authors. The claim that “ You, and your group, have publicly admitted to sending known-buggy patches” may not be totally accurate (or it might be—Pakki could be on other papers I’m not aware of), but it’s not totally inaccurate either. Most academic work is variations on a theme, so it’s reasonable to be suspect of things from Lu’s group.

As Greg KH notes, he has no time to deal with such BS, when suggested to write a formal complain. He has no time to play detectives: you are involved in a group that does BS and this smell like BS again, banned.

Unfair? Maybe: complain to your advisor.

Re: “They introduce kernel bugs on purpose”

#700
post #697
post #687

Whoa this is some heavy DC, a Chinese spy got busted trying to poison the Linux kernel. And then he came up with an excuse.

just because they chose to use Chinese names, doesnt make them less American. Are you suggesting non-Chinese Americans cant be spies?

Are you saying, in this particular case, that the Chinese researcher is an American citizen? That's a very bold claim. Source?
Post reply on HN