Open letter from researchers involved in the “hypocrite commit” debacle • Hacker News Board

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

#331

Post by neatze » Sun, Apr 25, 2021, 5:34 PM UTC

pcl wrote: post #235

createdapril24 wrote: post #49

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 agree with the approach you’ve outlined. I also empathize with the plight of the researchers — Linux is a bit different than normal Red Team engagements, in that a normal organization has a hunch of administrative / management layers who typically do not participate in the operations of the system being tested. A VP of engineering at a medium to large company is unlikely to be committing code, much less maintaining…

Why do you think there will be any change in behavior ?

It is not like community members are not for look out for bad commits on every new commit from most committers any way, since at least 2003, I think substantially earlier.

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

#332

Post by ajarmst » Sun, Apr 25, 2021, 5:34 PM UTC

neatze wrote: post #327

ajarmst wrote: post #320

Earlier quoted context omitted.

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 stu…

Out of curiosity, study where humans are deceived about the fact that they are research subjects can be justified in general ? (to me seems like correct answer no) Some relevant cases; the Facebook case[0] suggests it is justified because of EULA, and court determination test[1] is complicated for me to comprehend (to be honest), but seems like most relevant to this discussion. [0] https://www.theatlantic.com/technol…

I'm not qualified to comment on legal issues and contracts. In the case of EULAs, my understanding is that no contract where you surrender fundamental rights is valid or enforceable. But even then, I'd want a lawyers advice before assuming it. And, of course, that's a good argument for reading EULAs very carefully.

I've learned over several decades that any simple pronouncement that "X is ethical/unethical" is an effective way of ensuring that you will be wrong about some particular case. Yes, I think there might be cases where it is justified, but it would be very rare and require extremely careful monitoring and review. Two areas where it might come up would be medical research and research on children or adults of diminished capacity. In the former, there might be situations where the value of the research to the collective health and safety of the entire community would be sufficient to balance the use of such deception. In the latter, it may not be possible for your subjects to give informed consent (side note: this is, of course, also a ethical problem in experimentation on animals). The ethical dimensions of parents or guardians consenting to experimentation on their charges is extremely complex.

I will go out on a short limb and assert that ethical experimentation using that sort of deception depends a great deal on the details of a given case. Very subtle changes in the experimental protocol could easily change its ethical acceptability.

P.S: And, of course, there are a vast number of things that are completely legal but absolutely unethical.

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

#333

Post by lynndotpy » Sun, Apr 25, 2021, 5:34 PM UTC

Bootvis wrote: post #182

lynndotpy wrote: post #174

Earlier quoted context omitted.

It seems like a nitpick to me, since the rest of the apology uses the proper choices of words, though. "The method used was inappropriate", "we made a mistake", etc. The apology is also specific about what they did wrong despite their intentions. It really is a good apology after reading past the first six words.

ESL here. How correct is it to use ’any harm’ to mean ‘all harm’.

As others have said, 'any harm' implies that there might be none, while 'all harm' implies there is definitely some harm. So, 'all harm' is definitely the better choice of words for an apology (in this context.)

I am surprised to see people hung up on this, because the rest of the letter acknowledges specific harms done. To me, it really seems like a minor thing, and something that I might have written (as a native English speaker.)

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

#334

Post by posixplz » Sun, Apr 25, 2021, 5:34 PM UTC

BeetleB wrote: post #172

kfarr wrote: post #155

Earlier quoted context omitted.

I would argue at this point in collective awareness of public communications, using a form of "sorry if I did any harm" regardless of specific words used is an explicit decision by the writer to not accept full culpability. I agree with original comment, when you see a weasel apology introduction, reading the rest is of little value.

> I would argue at this point in collective awareness of public communications, using a form of "sorry if I did any harm" regardless of specific words used is an explicit decision by the writer to not accept full culpability. Based on my experience with the general public, with academics, and with industry folks, the criteria for what constitutes a sincere apology is not known by the majority. Furthermore, many of th…

“I’m sorry if I hurt you,” is a very different statement from, “I am sorry I hurt you.” One makes responsibility conditional, and the other takes responsibility.

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

#335

Post by ric2b » Sun, Apr 25, 2021, 5:41 PM UTC

createdapril24 wrote: post #317

llimos wrote: post #279

Earlier quoted context omitted.

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…

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

How do you do this without a browser vulnerability (and assuming it's not also XSS/CSRF like the previous point)?

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

#336

Post by createdapril24 » Sun, Apr 25, 2021, 6:18 PM UTC

ric2b wrote: post #335

createdapril24 wrote: post #317

Earlier quoted context omitted.

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…

> 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). How do you do this without a browser vulnerability (and assuming it's not also XSS/CSRF like the previous point)?

You can do this with chains of vulnerabilities, including but not limited to insecure redirects, CSP bypasses, insecure cookies. Another useful technique is session fixation - you give your victims sessions you've started and often their SSO experience will connect _their_ credentials to _your_ session.

Also to distinguish between #3 and, XSS in #2 was intended to mean "persistent stored XSS" as opposed to "reflected XSS". In the case of reflected XSS, this can be chained with CSP bypasses and insecure cookies to grab out e.g. bearer tokens.

My overall point is that heap fung shui 0day not required for 1-click ownage. In practice, I've not had to burn browser 0day to compromise organizations or their customers.

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

#337

Post by cutemonster » Sun, Apr 25, 2021, 6:59 PM UTC

createdapril24 wrote: post #317

llimos wrote: post #279

Earlier quoted context omitted.

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…

> I've run such phishing campaigns

To test if employees are easy to pish, or was it for real (black hat)?

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

#338

Post by rincebrain » Sun, Apr 25, 2021, 7:30 PM UTC

nuclearnice1 wrote: post #330

rincebrain wrote: post #324

Earlier quoted context omitted.

FWIW, there are no patches committed that I can find since 2013 that are not by people who are or were in the relevant lab at UMN. Maybe my research is flawed, but I don't think the bulk revert is currently hitting anyone but them. [1] - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

It’s a good observation. So for example we have a 2019 commit by Wenwen Wang being reverted. Wenwen is now at UGA. The commit is “ALSA: usx2y fix a double free bug” review by Takashi Iwai confirms it’s a good fix. I don’t agree with Greg K-H threatening to trash Wenwen’s work, his reputation, and add bugs to the Linux kernel out of spite toward researchers than Wenwen hasn’t worked with in years. Note that Aditya Pak…

The complaints, depending on who you were listening to, were that the patches were superfluous (cf. [1], where Aditya apparently later claimed "The patch is garbage") or contained security flaws (cf. [2] for one such allegation) , whether deliberate or accidental, and that too many of them had been accepted without enough review by dint of being "trivial fixes". (One claim, for example, was "I took a look on 4 accepted patches from Aditya and 3 of them added various severity security "holes"." [3], which, if false, should certainly probably provoke an apology.)

Assuming [3] came from a reasonably trustworthy source after Greg's initial distrust and frustration, combined with Aditya's reply of being extremely offended that anyone would doubt his work (which, if we assume for a moment he wasn't aware of the researchers' prior work poisoning LKML's opinion of the lab, could be a reasonable reaction), it's not surprising that his conclusion was "rip out all the patches for now and re-review them as we have time".

People keep overlooking that the plan was never "permanently remove the patches", it was always "remove the patches for now and then re-review them all".

And now it's working as expected - people are re-reviewing the patches proposed for removal and going "hey this is fine", "hey this is harmless", or occasionally, probably "hey this is bad". (I have not read anywhere near all the replies to the thread, I'm just assuming that the people who were complaining about the patches were also operating in good faith and not just making up complaints.)

I don't really see another reasonable way to have acted if you suspect a group of people has been generating and getting committed poor patches, whether out of malice or ignorance, than removing them for now and re-reviewing them.

If it turns out that the patches were (probably, since I don't think there's any absolute confidence to be had here) merely bad and not malicious, then sure, an apology would be warranted for claiming malice where there was none. (And for those who don't think he ever claimed malice, like I did when I started writing this reply, see [4], specifically 'Commits from @umn.edu addresses have been found to be submitted in "bad faith" to try to test the kernel community's ability to review "known malicious" changes.')

But I don't think "okay we need to re-review all these patches (and the usual thing to do if we need to re-review patches is remove them for now)" warrants an apology in itself.

[1] - https://github.com/torvalds/linux/commit/799bac5512188522213...

[2] - https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/

[3] - https://lore.kernel.org/linux-nfs/YH+zwQgBBGUJdiVK@unreal/

[4] - https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...

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

#339

Post by jdsully » Sun, Apr 25, 2021, 7:30 PM UTC

darawk wrote: post #160

juliansimioni wrote: post #91

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 is probably because they don't mean the apology, they were forced to write it by their administrators. And to be honest, I kind of agree with them. I don't really see what they did here as particularly bad. They demonstrated a very serious vulnerability in the linux kernel development process. I guess the harm they caused was wasting maintainers time, a bit? But what we all got out of it is the knowledge that re…

Their biggest crime seems to be they just aren't great developers. If you look at the patches they presented which to their knowledge were correct you'd see they couldn't have done anything useful. Because of their earlier work this was taken as intentional malice, but if they had been submitting great work it wouldn't be an issue.

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

#340

Post by createdapril24 » Sun, Apr 25, 2021, 7:42 PM UTC

cutemonster wrote: post #337

createdapril24 wrote: post #317

Earlier quoted context omitted.

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…

> I've run such phishing campaigns To test if employees are easy to pish, or was it for real (black hat)?

The former _only_.

I'm usually not testing only whether employees are easy to phish (the answer is pretty much 100% yes). I'm testing end-to-end: can you as a company prevent me from phishing through email protections? Can you detect when I'm phishing your employees? Will your employees report potential phishing emails? Can you figure out (without me telling you) which employees were targeted and which attacks were successful? Can you figure out which credentials/machines would need to be quarantined/rotated/examined?