Open Source Sabotage

A reminder that not only open-source projects are at risk of sabotage from trusted members.

It's open source.Everybody would be able to see it. It might be hard to figure out, but you couldn't get away with it forever.For that matter anybody who contributes to Linux could contribute a bad patch. Remember that a bad patch doesn't have to look like it has evil intent, it just looks like the author wasn't being careful with memory and... oops, there is a buffer overflow there.

It says they've cleared out homakov's modification, but I gather this vulnerability has been around for a long time. Is it paranoid to worry about malicious commits to other github repositories? (By other more surreptitious parties?)

The sketchy part is it was changed and shipped silently and in a sneaky way, and if it wasn’t for some developer to notice it, he wouldn’t have mentioned it.. However, no need to pushback or anything, consider the maintainer got hit by a bus, fork it, and take it from there.Also, the “security” guy claiming no one is going to read it, do you read linux kernel every update? No, not you, but other developers do, or whenever someone is interested/auditing they can, that kind of arguments a

Considering how long bugs can go unfixed and undetected even in large open source projects, I think it can totally happen. Just create a backdoor that looks like an honest mistake, submit it in a PR that adds some feature or fix, and exploit it at will as people update. Heartbleed took over 2 years to find and fix.

Accepting code from any source without properly reviewing it is surely the actual problem, no? This person only infiltrated this project because there was no proper oversight.Maintainers need to be more stringent and vigilant of the code they ship, and core projects that many other projects depend upon should receive better support, financial and otherwise, from users, open source funds and companies alike. This is a fragile ecosystem that this person managed to exploit, and they likely weren

What the uni guys did was correct. The Linux devs only able to review their codes because they are alerted. I am very sure there are plenty of bad faith commits that were accepted by Linux devs. For one, any governments with interest for backdoors with resources beyond the combine all Linux devs would have done it. Instead of appreciating what the uni did, they go beserk because their ego bruised. I am not surprised if within the next 5 years we going to hear more about this issue just that this

Interesting tidbit from the prof's CV where he lists the paper, interpret from it what you will[1]:> On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits> Qiushi Wu, and Kangjie Lu.> To appear in Proceedings of the 42nd IEEE Symposium on Security and Privacy (Oakland'21). Virtual conference, May 2021.> Note: The experiment did not introduce any bug or bug-introducing commit into OSS. It demonstrated weakness

Wouldn't it be relatively trivial for someone to compile, compare checksums and call them out?It's more likely they'd introduce a security flaw that is hard to detect in the OSS code. If someone finds, they'd just claim it was a security incident which is now fixed (and then they'd move to another masked flaw).

I mean it's so inexplicably bad that it's hard to imagine it being an innocent mistake.You have to wonder if opening a ticket for such a feature then having someone (or yourself under another account) build it in such an egregious way is a possible vector for deliberately creating such exploits.If this feature was default enabled, then it's even more suspect. It's just such an esoteric thing.When you factor in this kind of thing with recent revelations about backdoor