Footnote example given for "vulnerabilities into even large projects" is not valid/misleading

[zyansheep]

Affected page

https://www.privacyguides.org/en/basics/common-misconceptions/

Description

Hi PrivacyGuides maintainers!

I think I found a misleading in the "Common Misconceptions" article.

"The open development process has also sometimes been exploited to introduce new vulnerabilities into even large projects."

I believe the footnote for this sentence is misleading as none of the patches submitted by the UMN researchers actually made it into any official branch (and definitely not published in an official kernel release). All were rejected by maintainers before making it past the review stage. See the Kernel Report and the corresponding acknowledgement from UMN. While attacks on smaller projects, i.e. dependency-chain attacks are definitely common in various language ecosystems (and can potentially have huge knock-on effects), I can't find an instance where a large project with multiple maintainers had a malicious commit introduced that wasn't immediately caught or reverted.

If someone else can find a notable instance where a vulnerability was maliciously introduced into a large open source project, I think the footnote link should be changed to that. Otherwise, I think the sentence should be removed or caveat-ed in some manner.

I am willing to submit a PR if that is convenient :)

Sources

Sources linked in Description

Before submitting

• I am reporting something that is verifiably incorrect, not a suggestion or opinion.
• I agree to the Community Code of Conduct.

[dngray]

I hadn't actually noticed that and don't believe it is the correct source to use.

A better one to use would have been the The Linux Backdoor Attempt of 2003, however that's so long ago now it's likely sign-off process now is more stringent.

I don't believe this source even needs to exist, so I would be happy to see it's removal.

[zyansheep]

Should I submit a pull request?

[jonaharagon]

I'd have to look again, but my understanding was that the patches didn't make it in because they were pulled by UMN, not because they were caught by the review process. Thus it was a suitable warning about the development process' shortcomings.

In their paper, Lu and Wu claimed that none of their bugs had actually made it to the Linux kernel — in all of their test cases, they’d eventually pulled their bad patches and provided real ones. Kroah-Hartman, of the Linux Foundation, contests this — he told The Verge that one patch from the study did make it into repositories, though he notes it didn’t end up causing any harm.

https://www.theverge.com/2021/4/30/22410164/linux-kernel-university-of-minnesota-banned-open-source

[zyansheep]

The kernel's report on the issue says:

Summary of "Hypocrite Commits" patch attempts

All patch submissions that were invalid were caught, or ignored, by the Linux kernel developers and maintainers. Our patch-review processes worked as intended when confronted with these malicious patches.

But there was one patch which the kernel devs say was valid, but the researchers said was invalid?

This change was valid. The author's attempt to create an invalid change
failed as they did not understand how the PCI driver model worked within
the kernel. They asked for clarification about this change after the
maintainer accepted the change, and were told that it was acceptable.
Why the authors claimed in the submitted paper that this was an
incorrect change is not clear.

It seems like there is some ambiguity as to whether or not the kernel review system is actually something to be majorly concerned about. Given that the risk for vulnerabilities being purposely introduced into the linux kernel has not been clearly demonstrated, I think link on privacyguides should be changed to a more clear-cut example (if there even is one for a big open source project), or perhaps instead the section should talk about the much more concerning practice of supply-chain attacks where malicious code one way or another gets introduced into a small project which then gets included as a dependency in bigger projects. SolarWinds might be the biggest example of this, but there are many, many others.

[dngray]

I think link on privacyguides should be changed to a more clear-cut example

This would be something I would be open to, if you know of one off the top of your head. I know about various module mis-names in various language pkg managers, but I'd like something a bit more substantial than that

I guess there's the backdoor attempt of 2003, but that is quite some time ago and no doubt processes have improved since then such as only having one source repo in git and using signed commits.

[zyansheep]

Welp, I suppose we could mention the liblzma/xz exploit. Not sure if we could get a more clear example than that! 🤔

[dngray]

Might incorporate this in with #2467 as it's all really related in the same way.