Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

181–190 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#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 Pakki, writes a reply taking offense at the 'slander' and indicating that the commit was in good faith[1].

Greg KH then immediately calls bullshit on this, and then proceeds to ban the entire university from making commits [2].

The thread then gets down to business and starts coordinating revert patches for everything committed by University of Minnesota email addresses.

As was noted, this obviously has a bunch of collateral damage, but such drastic measures seem like a balanced response, considering that this university decided to _experiment_ on the kernel team and then lie about it when confronted (presumably, that lie is simply continuing their experiment of 'what would someone intentionally trying to add malicious code to the kernel do')?

* Abhi Shelat also chimes in with links to UMN's Institutional Review Board along with documentation on the UMN policies for ethical review. [3]

[1]: Message has since been deleted, so I'm going by the content of it as quoted in Greg KH's followup, see footnote 2

[2]: https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah...

[3]: https://lore.kernel.org/linux-nfs/3B9A54F7-6A61-4A34-9EAC-95...

Re: “They introduce kernel bugs on purpose”

#182
post #155

As a user of the linux kernel, I feel legal action against the "researchers" should be pursued.

I feel somewhat similar. Since I am using Linux, they ultimately were trying to break the security of my computers. If I do that with any company without their consent, I can easily end up in jail.

>they ultimately were trying to break the security of my computers.

No they weren't. They made sure the bad code never made it in. They are only guilty of wasting peoples time.

Re: “They introduce kernel bugs on purpose”

#183
post #128
post #86

Someone does voluntary work and people think that gives them some ethical privilege to be asked before someone puts their work to the test? Sure it would be nice to ask but at the same time it renders the testing useless. They wanted to see how the review goes if they aren't aware that someone is testing them. You cant do this with consent. The wasting time argument is nonsense too its not like they did this thousand…

> They wanted to see how the review goes if they aren't aware that someone is testing them. You cant do this with consent. Ridiculous. Does the same apply to pentesting a bank or a government agency. If you wanted to pentest these of course you'd get approval from an executive that has power to sanction this. Why would Linux development be an exception? Just ask GKH or someone to allow you to do this.

It's just a prank bro!

Re: “They introduce kernel bugs on purpose”

#184

From https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N... , > A lot of these have already reached the stable trees. If the researchers were trying to prove that it is possible to get malicious patches into the kernel, it seems like they succeeded -- at least for an (insignificant?) period of time.

It may be unethical from an academic perspective, but I like that they did this. It shows there is a problem with the review process if it is not catching 100% of this garbage. Actual malicious actors are certainly already doing worse and maybe succeeding. In a roundabout way, this researcher has achieved their goal, and I hope they publish their results. Certainly more meaningful than most of the drivel in the acade…

The paper indicates that the goal is to prove that OSS in particular is vulnerable to this attack, but it seems that any software development ecosystem shares the same weaknesses. The choice of an OSS target seems to be one of convenience as the results can be publicly reviewed and this approach probably avoids serious consequences like arrests or lawsuits. In that light, their conclusions are misleading, even if the attack is technically feasible. They might get more credibility if they back off the OSS angle.

Re: “They introduce kernel bugs on purpose”

#185
So FOSS is insecure if maintainers are lazy? This would hold true for any piece of software, wouldn't it? The difference here is that even though the "hypocrite commits" /were/ accepted, they were spotted soon after. Something that might not have happened quite as quickly in a closed source project.

Re: “They introduce kernel bugs on purpose”

#186
post #86

Someone does voluntary work and people think that gives them some ethical privilege to be asked before someone puts their work to the test? Sure it would be nice to ask but at the same time it renders the testing useless. They wanted to see how the review goes if they aren't aware that someone is testing them. You cant do this with consent. The wasting time argument is nonsense too its not like they did this thousand…

A far better approach would be to study patch submissions and see how many bugs were introduced by the result of those patches being accepted and applied, without any interference of any kind. Problem with that is it's a lot of work and they didn't want to do it in the first place.

Exactly, they are just seem mad and blame other for "wrong doings" instead of acknowledging that they need to improve.

Re: “They introduce kernel bugs on purpose”

#187

From https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N... , > A lot of these have already reached the stable trees. If the researchers were trying to prove that it is possible to get malicious patches into the kernel, it seems like they succeeded -- at least for an (insignificant?) period of time.

There’s no research going on here. Everyone knows buggy patches can get into a project. Submitting intentionally bad patches adds nothing beyond grandstanding. They could perform analysis of review/acceptance by looking at past patches that introduced bugs without being the bad actors that they apparently are. From FOSDEM 2014, NSA operation ORCHESTRA annual status report. It’s pretty entertaining and illustrates tha…

> They could perform analysis of review/acceptance by looking at past patches that introduced bugs without being the bad actors that they apparently are.

Very good point.

Post reply on HN