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

721–730 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#721

Post by wolverine876 »

I don't see the difference between these and other 'hackers', white-hat, black-hat etc. The difference I see is the institution tested, Linux, is beloved here.

Usually people are admired here for finding vulnerabilities in all sorts of systems and processes. For example, when someone submits a false paper to a peer-reviewed journal, people around here root for them; I don't see complaints about wasting the time and violating the trust of the journal.

But should one of our beloved institutions be tested - now it's an outrage?

Re: “They introduce kernel bugs on purpose”

#722

Post by tcelvis »

tcelvis wrote: post #664
gregkh wrote: post #267

Earlier quoted context omitted.

Thanks for the support. I also now have submitted a patch series that reverts the majority of all of their contributions so that we can go and properly review them at a later point in time: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...

Putting the ethical question of the researcher aside, the fact you want to "properly review them at a later point in time" seems to suggest a lack of confidence in the kernel review process. Since this researcher is apparently not an established figure in the kernel community, my expectation is the patches have gone through the most rigorous review process. If you think the risk of malicious patches from this person…

I guess what I am trying to get at is that this researcher's action does have its merit. This event does rise awareness of what sophisticated attacker group might try to do to kernel community. Admitting this would be the first step to hardening the kernel review process to prevent this kind of harm from happening again.

What I strongly disapprove of the researcher is that apparently no steps are taken to prevent real world consequences of malicious patches getting into kernel, I think the researcher should:

- Notify the kernel community promptly once malicious patches got past all review processes.

- Time these actions well such that malicious patches won't not get into a stable branch before they could be reverted.

----------------

Edit: reading the paper provided above, it seems that they did do both actions above. From the paper:

> 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. At the same time, we point out the correct fixing of the bug and provide our correct patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. All the UAF-introducing patches stayed only in the email exchanges, without even becoming a Git commit in Linux branches. Therefore, we ensured that none of our introduced UAF bugs was ever merged into any branch of the Linux kernel, and none of the Linux users would be affected.

So, unless the kernel maintenance team have another side of the story. The questions of ethics could only go as far as "wasting kernel community's time" rather than creating real world loop holes.

Re: “They introduce kernel bugs on purpose”

#723

Post by kerng »

andrepd wrote: post #679
beshrkayali wrote: post #335

This seems like a pretty scummy way to do "research". I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. It's not that they're doing this, I'm sure they're not the first to think of this (for research or malicious reasons), but having the gall to brag about it is a new low.

Devil's advocate, but why? How is this different from any other white/gray-hat pentest? They tried to submit buggy patches, once approved they immediately let the maintainers know not to merge them. Then they published a paper with their findings and which weak parts in the process they thing are responsible, and which steps they recommend be taken to mitigate this.

Very easy, if its not authorized it's not a pentest or red team operation.

Any pentester or red team considers their profession an ethical one.

By the response of the Linux Foundation, this is clearly not authorized nor falling into any bug bounty rules/framework they would offer. Social engineering attacks are often out of bounds for bug bounty - and even for authorized engagements need to follow strict rules and procedures.

Wonder if there are even legal steps that could be taken by Linux foundation.

Re: “They introduce kernel bugs on purpose”

#726

Post by FrameworkFred »

mort96 wrote: post #622
FrameworkFred wrote: post #567

This feels like the kind of thing that "white hat" hackers have been doing forever. UMN may have introduced useful knowledge into the world in the same way some random hacker is potentially "helping" a company by pointing out that they've left a security hole exposed in their system. With that said, kernel developers and companies with servers on the internet are busy doing work that's important to them. This sort of…

Your analogy doesn't work. A true "white hat" hacker would hack a system to expose a security vulnerability, then immediately inform the owners of the system, all without using their unintended system access for anything malicious. In this case, the "researchers" submitted bogus patches, got them accepted and merged, then said nothing, and pushed back against accusations that they've been malicious, all for personal…

You make a fair point. I'm just saying that, while it might ultimately be interesting and useful to someone or even lots of someones, it remains a crappy thing to do and the consequences that UMN is facing as a result is predictable and makes perfect sense to me, a guy who has had to rebuild a few servers and databases over the years because of intrusions and a couple of those have come with messages about how we should consult with the intruder who had less-than-helpfully found some security issue for us.

Re: “They introduce kernel bugs on purpose”

#728

Post by leeuw01 »

In a follow-up [1], the author suggests: OSS projects would be suggested to update the code of conduct, something like “By submitting the patch, I agree to not intend to introduce bugs”

How can one be so short-sighted?...

[1] https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....

Re: “They introduce kernel bugs on purpose”

#729

Post by bobthechef »

alpaca128 wrote: post #440
beshrkayali wrote: post #335

This seems like a pretty scummy way to do "research". I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. It's not that they're doing this, I'm sure they're not the first to think of this (for research or malicious reasons), but having the gall to brag about it is a new low.

> having the gall to brag about it is a new low Even worse: They bragged about it, then sent a new wave of buggy patches to see if the "test subjects" fall for it once again, and then tried to push the blame on the kernel maintainers for being "intimidating to newbies". This is thinly veiled and potentially dangerous bullying.

Why not just call it what it is: fraud. They tried to deceive the maintainers into incorporating buggy code under false pretenses. They lied (yes, let's use that word) about it, then doubled down about the lie when caught.

Re: “They introduce kernel bugs on purpose”

#730

Post by NationalPark »

mikaeluman wrote: post #727

Usually I am very skeptical of "soft" subjects like the humanities; but clearly this is unethical research. In addition to wasting people's time, you are potentially messing with software that runs the world.

Considering how often you post about free speech and censorship, maybe you would find some interesting perspectives within the humanities.
Post reply on HN