“They introduce kernel bugs on purpose” • Hacker News Board

Re: “They introduce kernel bugs on purpose”

#771

Post by mk89 » Wed, Apr 21, 2021, 7:26 PM UTC

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 have the same questions. So far we have focused on how bad these "guys" are. Sure, they could have done it differently, etc. However, they proved a big point: how "easy" it is to manipulate the most used piece of software on the planet.

How to solve this "issue" without putting too much process around it? That's the challenge.

Re: “They introduce kernel bugs on purpose”

#772

Post by saghm » Wed, Apr 21, 2021, 7:28 PM UTC

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

Thank you for all your excellent work!

Re: “They introduce kernel bugs on purpose”

#773

Post by dragonwriter » Wed, Apr 21, 2021, 7:29 PM UTC

dataflow wrote: post #206

walrus01 wrote: post #147

Earlier quoted context omitted.

> I think all patches have come from people currently being advised by Kangjie Liu[3] or Liu himself dating back to Dec 2018 New plan: Show up at Liu's house with a lock picking kit while he's away at work, pick the front door and open it, but don't enter. Send him a photo, "hey, just testing, bro! Legitimate security research!"

This is funny, but not at all a good analogy. There's obviously not remotely as much public interest or value in testing the security of this professor's private home to justify invading his privacy for the public interest. On the other hand, if he kept dangerous things at home (say, BSL-4 material), then his house would need 24/7 security and you'd probably be able to justify testing it regularly for the public's sa…

> This is funny, but not at all a good analogy

Yeah, for one thing, to be a good analogy, rather than lockpicking without entering when he’s not home and leaving a note, you’d need to be an actual service worker for a trusted home service business and use that trust to enter when he is home, conduct sabotage, and not say anything until the sabotage is detected and traced back to you and cited in his cancelling the contract with the firm for which you work, and then cite the “research” rationale.

Of course, if you did that you would be both unemployed and facing criminal charges in short order.

Re: “They introduce kernel bugs on purpose”

#774

Post by djhaskin987 » Wed, Apr 21, 2021, 7:29 PM UTC

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 weaknesses in the patching process in a safe way. No user was affected, and IRB exempt was issued. The experiment actually fixed three real bugs. Please see the clarifications[2].

1: https://www-users.cs.umn.edu/~kjlu/

2: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....

Re: “They introduce kernel bugs on purpose”

#775

Post by CommieBobDole » Wed, Apr 21, 2021, 7:31 PM UTC

tpoacher wrote: post #245

kop316 wrote: post #226

Earlier quoted context omitted.

Hearing how you phrased it reminds me of a study that showed how parachutes do not in fact save lives (the study was more to show the consequences of extrapolating data, so the result should not be taken seriously): https://www.bmj.com/content/363/bmj.k5094

This is now my second favourite paper after the atlantic salmon in fmri

I'm a big fan of Doug Zongker's excellent paper on chicken:

https://isotropic.org/papers/chicken.pdf

Re: “They introduce kernel bugs on purpose”

#776

Post by Klwohu » Wed, Apr 21, 2021, 7:32 PM UTC

rubyn00bie wrote: post #321

This is supremely fucked up and I’d say is borderline criminal. It’s really lucky asshole researchers like this haven’t caused a bug that cost billions of dollars, or killed someone, because eventually shit like this will... and holy shit will “it was just research” do nothing to save them.

Well it remains to be seen if they're foreign intelligence agents, doesn't it?

Re: “They introduce kernel bugs on purpose”

#777

Post by grae_QED » Wed, Apr 21, 2021, 7:32 PM UTC

This is insulting. The whole premise behind the paper is that open source developers aren't able to parse comits for malicious code. From a security standpoint, sure, I'm sure a bad actor could attempt to do this. But the fact that he tried this on the linux kernel, an almost sacred piece of software IMO, and expected it to work takes me aback. This guy either has a huge ego or knows very little about those devs.

Re: “They introduce kernel bugs on purpose”

#778

Post by seoaeu » Wed, Apr 21, 2021, 7:33 PM UTC

hpoe wrote: post #438

ltfish wrote: post #413

Some clarifications since they are unclear in the original report. - Aditya Pakki (the author who sent the new round of seemingly bogus patches) is not involved in the S&P 2021 research. This means Aditya is likely to have nothing to do with the prior round of patching attempts that led to the S&P 2021 paper. - According to the authors' clarification [1], the S&P 2021 paper did not introduce any bugs into Linux kerne…

It doesn't matter. I think this is totally appropriate. A group of students are submitting purposely buggy patches? It isn't the kernels team to sift through and distinguish they come down and nuke the entire university. This sends a message to any other University thinking of a similar stunt you try this bull hockey you and your entire university are going to get caught in the blast radius. In short "f** around, fin…

I seriously doubt this policy would have been adopted if other unrelated groups at the same university were submitting constructive patches.

Re: “They introduce kernel bugs on purpose”

#779

Post by furyofantares » Wed, Apr 21, 2021, 7:37 PM UTC

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…

To be clear, the quoted text in your post is presumably your own words, not a quote?

Re: “They introduce kernel bugs on purpose”

#780

Post by seoaeu » Wed, Apr 21, 2021, 7:38 PM UTC

temac wrote: post #757

ENOTTY wrote: post #22

Later down thread from Greg K-H: > Because of this, I will now have to ban all future contributions from your University. Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures. In t…

I don't feel sorry at all. If you want to contribute from there, show that the rogue professor and their students have been prevented from doing further malicious contributions (that is probably at least: from doing any contribution at all during a quite long period -- and that is fair against repeated infractions), and I'm sure that you will be able to contribute back again under the University umbrella. If you don'…

How could a single student or professor possibly achieve that? Under the banner of "academic freedom" it is very hard to get someone fired because you don't like their research.

It sounds like you're making impossible demands of unrelated people, while doing nothing to solve the actual problem because the perpetrators now know to just create throwaway emails when submitting patches.