Live data from Hacker News

Open letter from researchers involved in the “hypocrite commit” debacle

lore.kernel.org

261–270 of 384 posts

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#261
post #243

If we don't somehow make it socially acceptable to let any security researchers conduct the required social engineering to test supply chain attack susceptibility of OSS maintainers without tipping them off in advance, dangerous state actors -will- continue to do it and -not- tell anyone when they are successful. Punishing these researchers this harshly about bad manners is creating a chilling effect that will scare…

> If we don't somehow make it socially acceptable to let any security researchers conduct the required social engineering to test supply chain attack susceptibility of OSS maintainers without tipping them off in advance, dangerous state actors -will- continue to do it and -not- tell anyone when they are successful. What's the result of that? Lots of known bad patches being sent in, wasting everyone's time, because no…

This suggestion, if taken to it's logical conclusion in my mind, I should send an email to every open source project maintainer ever warning them that at some point in the future I might attempt to validate their 2FA settings or try to submit mildly malicious code to them to test their ability to do code review at some unknown date in the future.

Maybe this helps to raise awareness, even though in reality I will do tests like this to a tiiiiny percentage of repos over the next decade.

I don't really know what purpose this would serve other than making people realize everyone got the same message, and everyone going back to being just as complacent as they were... but now we technically informed it was going to happen so it is fine now?

Do any security researchers ask permission before finding other vulnerabilities in random open source code? I have never observed this.

I feel like this type of thing should be assumed to come from whitehats or blackhats always.

I for one teach everyone around me that if they can compromise me, they can have the bitcoin private key I leave on my personal systems. They earned it, and I will see that outgoing transfer on that address as a canary.

I have been compromised a couple of times in this game when multiple people colluded, and it only leveled up my opsec and threat model. Good.

IMO we should double down and raise grants to offer as bug bounties for people that successfully get potentially malicious code past code review in majorly depended on open source projects. We need to encourage a -lot- of this behavior to train people.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#262

This apology fails from the 5th word: "We sincerely apologize for any harm..." While there are other requirements, a sincere apology cannot in any way entertain doubt about the fact that there WAS harm. Truly acknowledging the harm done is foundational to a real apology, and most of us (myself included) end up sneaking in weasel words or phrases like this. Psychologically, its nice for the apologizer, since it allows…

Your critique seems more about waffle words in apologies and less about this specific apology. While they do waffle in that sentence, on the whole, their apology seems pretty sincere. They acknowledge their error and the harms they perceive they caused. As a linux user, I am inclined to accept.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#263
post #236

Earlier quoted context omitted.

There are literally companies you can hire that will go this far pentesting your company and the employees involved are not in on it. How else do you prove your process can stop real infiltrators by state actors?

So? The difference is consent (in your case of the owners of the company). There are many crimes in the world that are only crimes if you do it without consent. > How else do you prove your process can stop real infiltrators by state actors? One of the common security controls against infiltration by foreign nation states is espionage being a capital offense. Well obviously not appropriate, i think that its pretty ob…

So if we get consent from a C-level at a company, we don't need consent from every other lower level person we trick?

If you have approval from one person in an org of 100,000 is this still okay?

It has to be, because getting explicit consent from every person in the org at that size would be untenable, and make them artificially extra vigilant during a potential audit window.

Well now scale this to open source. The typical web project has 2k+ random nodejs libs in their dependency tree. These are all separate orgs/individuals.

Real world bad actors are backdooring these projects constantly. I specialize in this area of research.

If every white hat has to get permission from exponentially large dependency chains, they will never even come close to being able to compete with black hats here finding the weak links of the chain.

The blackhats set the rules of engagement, for better or worse. White hats should be free to go for it just like with any other vulnerability they evaluate.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#264
post #236

Earlier quoted context omitted.

There are literally companies you can hire that will go this far pentesting your company and the employees involved are not in on it. How else do you prove your process can stop real infiltrators by state actors?

> you can hire there lies the difference, duh.

And what about the hundreds of NPM dependencies in VS Code no one reviews?

Or the the thousands of brew packages that are blindly merged unsigned by 800 people with access?

Who pays to give a white hat as much freedom to find supply chain attack vectors here? Who gets consent from every random student whose code, if compromised, would compromise every major company?

We have created a massive mess, and I don't know that we will be able to hire enough researchers to fix it.

We are going to need unpaid volunteers, and a lot of them.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#265

we believe we have much to contribute in the future Please, you've contributed enough already, really.

Yeah. Please find another project, that doesn't involve deliberately breaking other people's work, and screwing up the kernel that a billion people rely on.

If that means changing jobs, most of us have been there. Looking for a job sucks, but if you screw up that badly, then you do have to consider stacking shelves in a supermarket; you're not fit to work on a public project of such importance.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#266
post #204

> We just want you to know that we would never intentionally hurt the Linux kernel community and never introduce security vulnerabilities. Our work was conducted with the best of intentions and is all about Uhh.. but that was the exact intent of the paper. And they did it successfully. So.. mission failed successfully? What a bizarre attempt to save-face. This is academic misconduct and they're trying to save their a…

Obviously the intent was never to introduce security vulnerabilities, no matter how naive and badly thought-out their methodology was. The intent was to show it could be done. None of the proposed vulnerabilities ever got in the kernel, whenever they were at risk of being accepted, the maintainer was warned and the process was aborted.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#267
post #243

If we don't somehow make it socially acceptable to let any security researchers conduct the required social engineering to test supply chain attack susceptibility of OSS maintainers without tipping them off in advance, dangerous state actors -will- continue to do it and -not- tell anyone when they are successful. Punishing these researchers this harshly about bad manners is creating a chilling effect that will scare…

FWIW I completely agree with you but I see no way out. The Linux kernel project needs and deserves the best security methods but (a) likely can't afford the people and (b) bringing more money aboard might draw unmotivated people only after the paycheck which could objectively deteriorate the project's code quality. Dual cryptographic signoff still doesn't address any social issues (or I'm grossly misunderstanding it…

Most projects have virtually no accountability at all.

Hundreds of people have blind push access to brew. Almost no one signs code. One bad commit and you backdoor every company in silicon valley that blindly executes the unsigned code from the brew repo. Pick a favorite Linux distro. All but a handful work the same way.

Right now an low skill level malicious party just needs to phish one of the ~90% of maintainers that don't have strong (or any) 2FA enabled anywhere in a dependency graph while they are on vacation or are not paying attention to a project and sneak in a commit or two into history while notifications are turned off. Attacks just like this have happened in the wild and not gone noticed for months. How many have we still not noticed?

It is insane we let it get to this point. I feel like we are in early 1900s medicine where only like 1/10000 doctors see the value in washing hands and tools.

Dual cryptographic signatures on all code from author/maintainer plus signatures by security-only reviewers from a pool not known in advance before new releases would be a very high bar for an adversary to defeat and a high risk of exposure.

I have helped deploy variations of this approach with clients/employers in the past, and will publishing more detailed recommendations along these lines publicly soon.

If the remaining weaknesses in this threat model and posture became our worst attack surface, we are in dramatically better shape.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#269
post #58

Supply chain attacks are the security buzzthreat of day, at least since Solarwinds. Mucking about with the Linux kernel would be a really juicy target for nation-state actors. If you wanted to study this risk, how would you go about doing it? I haven't done kernel work since BSD4.3 so my opinion isn't particularly interesting. With that said, I would agree that the researchers were naive and their approach has caused…

The question always is, could you have learned the same thing with less "invasive" methods? And I think there's a good argument here that that's the case: I.e. the researchers first looked at bugs in the kernel and how their history, finding that such scenarios happened by accident. They could likely have gotten bugs past reviewers they had told that they were trying something like this. lots of options, so going for the most extreme option to "find" something that's not exactly a new or widely disagreed idea is quite unnecessary.

Re: Open letter from researchers involved in the “hypocrite commit” debacle

#270

This apology fails from the 5th word: "We sincerely apologize for any harm..." While there are other requirements, a sincere apology cannot in any way entertain doubt about the fact that there WAS harm. Truly acknowledging the harm done is foundational to a real apology, and most of us (myself included) end up sneaking in weasel words or phrases like this. Psychologically, its nice for the apologizer, since it allows…

Wait. 'Any' can mean 'none at all' in this context?
Post reply on HN