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

821–830 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#821

Post by Fordec »

dm319 wrote: post #801
Fordec wrote: post #798

In Ireland there was a referendum to repeal the ban on abortion referendum there was very heated arguments, bot twitter accounts and general toxicity. For the sake of peoples sanity, there was a "Repeal Shield" implemented that blocked bad faith actors. This news makes me wish to implement my own block on the same contributors to any open source I'm involved with. At the end of the day, their ethics is their ethics.…

I think that is a sensible way to deal with this problem. The linux community is based on trust (as are a lot of other very successful communities), and ideally we trust until we have reason not to. But at that point we do need to record who we don't trust. It is the same in academia and sports.

The tech community, especially in sub-niches is far smaller than people think it is. It's easy to feel like it's a sea of tech to some when it's all behind a screen. But reputation is a powerful thing in both directions.

There is also a more nuclear option which I'm specifically not advocating for quite yet here but I will note none the less;

We're starting to see in discourse regarding companies co-opting open source projects for their own profit (cough Amazon) and how license agreements limit them more than regular contributors. That has come about, at the core of it, also because of a demonstrated trend of bad faith but also combined with a larger surface area contact with society. I could foresee a potential future trend where individuals who also act in bad faith are excluded from use of open source projects through their licenses. Imagine if the license for some core infrastructure tech like a networking library or the Linux kernel banned "Joe Blackhat" from using python for professional use. Now he still could, but in reputable companies, particularly larger ones with a legal department that person would be more of a liability than they are worth. There can be potentially huge professional consequences of a type that do not currently exist really in the industry.

Re: “They introduce kernel bugs on purpose”

#823

Post by aluminum96 »

motohagiography wrote: post #314

This isn't friendly pen-testing in a community, this is an attack on critical infrastructure using a university as cover. The foundation should sue the responsible profs personally and seek criminal prosecution. I remember a bunch of U.S. contractors said they did the same thing to one of the openbsd vpn library projects about 15 years ago as well. What this professor is proving out is that open source and (likely, o…

Not everything can be fixed with the criminal justice system. This should be solved with disciplinary action by the university (and possibly will be [1]).

[1] https://cse.umn.edu/cs/statement-cse-linux-kernel-research-a...

Re: “They introduce kernel bugs on purpose”

#824

Post by paxys »

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…

Pen testing is essential, yes, but there are correct and incorrect ways to do it. This was the latter. In fact attempts like this harm the entire industry because it reflects poorly on researchers/white hat hackers who are doing the right thing. For example, making sure your testing is non-destructive is the bare minimum, as is promptly informing the affected party when you find an exploit. These folks did neither.

Re: “They introduce kernel bugs on purpose”

#825

Post by g42gregory »

gregkh wrote: post #267
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…

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...

My deepest thanks for all your work, as well as for keeping the standards high and the integrity of the project intact!

Re: “They introduce kernel bugs on purpose”

#826

Post by whack »

dm319 wrote: post #799
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…

The world works better without everyone being untrusting of everyone else, and this is especially true of large collaborative projects. The same goes in science - it has been shown over and over again that if researchers submit deliberately fraudulent work, it is unlikely to be picked up by peer review. Instead, it is simply deemed as fraud, and researchers that do that face heavy consequences, including jail time. W…

If an open-source project adopt a trusting attitude, nation-states can and will take advantage of this, in order to inject dangerous vulnerabilities. Telling University professors to not pen-test OSS does not stop nation-states from doing the same thing secretly. It just sweeps the problem under the rug.

Would I prefer to live in a world where everyone behaved in a trustworthy manner in OSS? Absolutely. But that is not the world we live in. A professor highlighting this fact, and forcing people to realize the dangers in trusting people, does more good than harm.

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

On a non-serious and humorous note, this episode reminds me of the Sokal Hoax. Most techies/scientists I've met were very appreciative of this hoax, even though it wasn't conducted with pre-approval from the subjects. It is interesting to see the shoe on the other foot

https://en.wikipedia.org/wiki/Sokal_affair

Re: “They introduce kernel bugs on purpose”

#827

Post by neoflame »

Cpoll wrote: post #469
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...

A lot of people are talking about the ethical aspects, but could you talk about the security implications of this attack? From a different thread: https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N... > A lot of these have already reached the stable trees. Apologies in advance if my questions are off the mark, but what does this mean in practice? 1. If UNM hadn't brought any attention to these, would they h…

I don't think the attack described in the paper actually succeeded at all, and in fact the paper doesn't seem to claim that it did.

Specifically, I think the three malicious patches described in the paper are:

- UAF case 1, Fig. 11 => crypto: cavium/nitrox: add an error message to explain the failure of pci_request_mem_regions, https://lore.kernel.org/lkml/20200821031209.21279-1-acostag.... The day after this patch was merged into a driver tree, the author suggested calling dev_err() before pci_disable_device(), which presumably was their attempt at maintainer notification; however, the code as merged doesn't actually appear to constitute a vulnerability because pci_disable_device() doesn't appear to free the struct pci_dev.

- UAF case 2, Fig. 9 => tty/vt: fix a memory leak in con_insert_unipair, https://lore.kernel.org/lkml/20200809221453.10235-1-jameslou... This patch was not accepted.

- UAF case 3, Fig. 10 => rapidio: fix get device imbalance on error, https://lore.kernel.org/lkml/20200821034458.22472-1-acostag.... Same author as case 1. This patch was not accepted.

This is not to say that open-source security is not a concern, but IMO the paper is deliberately misleading in an attempt to overstate its contributions.

edit: wording tweak for clarity

Re: “They introduce kernel bugs on purpose”

#829

Post by Floegipoky »

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…

Setting aside the ethical aspects which others have covered pretty thoroughly, they may have violated 18 U.S.C. §1030(a)(5) or (b). This law is infamously broad and intent is easier to "prove" than most people think, but #notalawyer #notlegaladvice. Please don't misinterpret this as a suggestion that they should or should not be prosecuted.

Re: “They introduce kernel bugs on purpose”

#830

Post by philjackson »

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 mean, it's the linux kernel. Think about what it's powering and how much risk there is involved with these patches. Review processes obviously aren't perfect, but usually patches aren't constructed to sneak sketchy code though. You'd usually approach a review in good faith.

Given that some patches may have made it though with holes, you pull them and re-approach them with a different mindset.

Post reply on HN