Live data from Hacker News

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

lore.kernel.org

311–320 of 384 posts

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

#311

People here don’t seem to be convinced. There’s a good amount of defense in this letter, so I get it, and it could have been framed better, but ultimately it seems like they learned a valuable lesson and have value to add, so why not let people learn from mistakes and move on? They’ve already been publicly shamed…

Reading this thread I am saddened to see hn apparently conform to the law of maximum offence. We see the least charitable explanation for everything said in the apology because outrage gets upvotes.

there's "assume good faith", and then there's "assume good faith of someone with a documented record of bad faith." The present case is the second. Assuming good faith in this apology is not sensible in the face of the existing evidence. Their goal seems to have been to generate a paper, and they haven't withdrawn that paper.

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

#312

There is a major error made by the research group. It starts and ends here: "we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches." I am a Red Teamer and work with companies to understand how their detective/preventative/recovery controls and processes are working. Here's how you resolve this: You work with maintainers to get t…

> You work out a mechanism to prevent submitted patches from being merged (e.g. maintainers are notified before bad patches accepted by code review processes are merged). It is my understanding that this happened and that no bad patches were actually merged.

Except there was no consent from maintainers here.

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

#313

to the folks picking this apart word-by-word: all evidence suggests that two of the signatures are natives of china, and the third of india. it is reasonable to credit them with not being native english speakers.

there's no way this didn't go through multiple layers of review

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

#314
Greg K-H replied:

> Thank you for your response.

> As you know, the Linux Foundation and the Linux Foundation's Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community.

> Until those actions are taken, we do not have anything further to discuss about this issue.

Was this letter publicly released?

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

#315
post #135

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…

This interpretation looks flawed. You discredit the entire message based on a single word--a very general word whose meaning you pinned to a definition which results in the most negative interpretation--and you also ignore the fact that they explicitly state the damage it caused in the same paragraph. To clarify: I'm not arguing this is a good or bad apology; just that the justification provided here looks flawed. Hu…

Strong disagree. You should always apologize for _what you did_ not the _effects_ of what you did. Lead with and more strongly emphasize your actions and how they were inappropriate.

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

#316

To summarize: -they apologize for the three patches in 2020 -they claim asking permission would have defeated their research -they claim the other 200 were legitimate patch attempts (a sample of which were, from my personal reading, from 'innocuous but useless' to 'slightly harmful'). Hard to believe, but plausible.

> they claim asking permission would have defeated their research But surely this proves malice aforethought. If you interact with someone under false pretences to deliberately mislead them, then you are effectively lying to them. In fact, if you are doing so in order to receive something of value from them (such as their time reviewing your code) then it could even be seen as fraud. Did they tell their IRB that thei…

I would like see their research proposal to answer some of these questions. That probably won’t happen though.

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

#317
post #279

Earlier quoted context omitted.

Just clicking the link is enough to fail? No need to enter private info or execute downloaded files? Either your phising emails are badly crafted or you expect employees to see the future.

Agreed. This is something that made me very annoyed when they did it to us. I know exactly what I'm doing, I know that you can't infect a computer from opening a link unless the attacker possesses a new browser 0-day, and expecting your average employee to worry about new browser 0-days is ridiculous. If it were an obvious phishing URL, like a variation on the company domain, then fine (maybe). But it wasn't.

I've run such phishing campaigns where the link:

1. (Windows specific) Opens up a Windows file share, which causes the person to authenticate to the file share, which through PtH/Responder results in their enterprise credentials being stolen.

2. Exploited a XSS or CSRF attack on an internal/management endpoint. Which in turns allows a pivot from external to internal access.

3. Steals a web session, cached password or authentication token, resulting in compromise of employee credentials to be used elsewhere (e.g. reused to access enterprise VPN).

These are just some not-a-browser-0day examples of a single click being game-over dangerous.

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

#318

There is a major error made by the research group. It starts and ends here: "we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches." I am a Red Teamer and work with companies to understand how their detective/preventative/recovery controls and processes are working. Here's how you resolve this: You work with maintainers to get t…

>I am a Red Teamer and work with companies OK, how do you test SocEng vectors? Do you obtain consent and coordinate with every employee that might be targeted to receive your e-mail? >You also study submitting from yandex, gmail, .cn and other email addresses No, the point was submitting from a known and respectable entity, which might affect the level of scrutiny. They weren't testing a whole patching process, but a…

> No, the point was submitting from a known and respectable entity

They weren't, though - their own paper explicitly says they used newly created Gmail addresses for the patches...

"We submit the three patches using a random Gmail account to the Linux community and seek their feedback—whether the patches look good to them."

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

#319

Earlier quoted context omitted.

But they did not introduce security vulnerabilities as there prevented the bad patches from being merged

Those measures were insufficient, as according to the developers, a number of the bogus patches were merged and had to be reverted.

Sort of?

The "hypocrite commits", according to the researchers' own paper, originated from "random Gmail addresses", and the researchers continue to claim none of those got merged (though since they haven't told us what they were, ...)

The additional claim is that some of the commits not covered by their "hypocrite commits" (and thus, submitted from their UMN addresses) contained security bugs, deliberate or not, and the loss of trust in the researchers is sufficient to justify reverting all of their commits until they can be reviewed.

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

#320
post #198

Earlier quoted context omitted.

Thank you for such detailed response. Can there be ethical possibility (highly remote one) where an study (assuming it is objectively justified) conducted with deception, but without prior informed consent at all. (eg. human subjects will not know that there's time is used for another purpose)

Doesn't this happen all the time? Many psychology studies are done by bringing in test subjects, asking for their consent to be interviewed or tested under the guise of studying X, when in fact the researchers are looking to evaluate Y instead? E.g. I the researcher ask if you consent to spending 30min completing a series of tasks to sort objects by their shape, presumably because I want to study your ability to reco…

TLDR: Yes, but deceiving a subject about the details of how they are being studied is different from deceiving them about the fact that they are a research subject.

Yes, this happens all the time. But note the salient features: (1) the subjects are aware that they are research subjects and have agreed to participate (albeit without full knowledge of how the collected data will be analyzed). They have agreed to be studied, and have agreed that their time may be used in pursuit of this research. (2) All such studies undergo a very stringent ethical review and are usually monitored closely by third parties (at least since Milgram made it extremely clear that this was a necessary policy). These issues are complex and difficult to navigate---which is precisely why we have review boards. Every experiment has to be evaluated to balance the requirement to act ethically with the value of the research data to be collected. Skipping that requirement is unacceptable.

In my experience, the moment a research team starts looking for reasons not to classify what they are doing as human experimentation is the moment when it becomes extremely clear that they need board review.

Post reply on HN