Personally, I would've released the PoC back in July when they said the problem was resolved. No need to ask if the quote can be used, it's exactly what they told the security researchers after all.
Effectively paying people (and heaping ego gratification on top of that) to be silent about found vulnerabilities.
1. You tested someone else's servers, and not software running on your own computer, and you didn't get permission or adhere to the rules of engagement the target established. Now you're not a researcher, you're an intruder, subject to CFAA. There's a bright line in US law between your computer and someone else's computer.
2. You tested software running on your own computer, but you acquired that software by agreeing to a contract prohibiting research, reverse engineering, or disclosure (ie: any NDA). Now you've violated a contract, and can be sued civilly for doing so. This comes up a fair bit when testing stuff on behalf of big enterprises, where all the software acquisitions come with big, enforceable contracts. I've had to cave a bunch of times on disclosures because of this; most memorably, I got locked in a vendor's suite at Black Hat an hour before my talk redacting things, because that vendor had a binding contract with my consulting client.
3. You were wrong about the vulnerability, or it could plausibly be argued that you were wrong, and you made a big stink about it. You're still a researcher, but you've also possibly defamed the target, which is a tort that you can be sued for.
4. You disclosed a vulnerability that you'd previously leaked, or provided exploit tooling regarding, to a criminal enterprise. Now you're not a researcher, you're an accomplice to the criminal enterprise. This has come up with people writing exploits for carding rings --- they weren't (or couldn't be proved to be) carders themselves, but they explicitly and knowingly enabled the carding.
As you can see, disclosing vulnerabilities isn't the least scary thing you can do with speech in the US, but it's not that much more scary than, say, leaving a nasty Yelp review for a dentist's office (something that also gets people sued). Just (a) don't test servers and (b) don't give secret bugs to organized criminals.
The thing that seems a little iffy for me with crowdstrike is that it’s an agent that calls back to services. It seems plausible that I could unintentionally break something in their environment while testing their software.
I like how you wrapped it up though and totally agree.
It created a lot of friction but I kind of understand the policy.
Dropping a zero day on the public is never acceptable, regardless of how disingenuous a device manufacturer is being. Bug disclosure without a known remedy has to be an absolute last resort kind of thing, and it's actually a little upsetting that modzero used that tactic as a kind of threat ("As the issue was not considered valid, we informed CrowdStrike that we would release the advisory to the public.")
I don't think it is upsetting at all.
"We found a vulnerability"
"There's no vulnerability"
"No, you misunderstand, here's how it works and how to exploit"
"Naah, no vulnerability"
"Ok, if there's no vulnerability as you claim, you don't mind us releasing our findings to the public, right?"
Imagine if you took a new job and they had a bunch of hardware sitting around from such a vendor. Would you be OK if someone published an exploit for your systems?
(In this case, the vulnerability seems minor, so it's sort of academic. But I'm not understanding the mindset of the people here who want to see this as a two party adversarial kind of relationship between Modzero and CrowdStrike. It's not!)
Modzero was even following a more conservative playbook here: not setting a deadline from the start, but only talking about release once the vendor indicated there was no issue (anymore).
Telling people that the product they rely on has vulnerabilities is clearly not the same thing as "release the vulnerability report" though, is it? I still remain amazed at the absolutism in the arguments here. There is a spectrum of responses that can be explored before dropping bombs. But everyone wants to see stuff burn?
Without the necessary details telling the public about a vulnerability is like shouting at a wall. Publishing the details forces vendors to release fixes when they deny the existence of the vulnerability.
This isn't some hidden password or evil DoS attack, this is an attack only processes with admin access can leverage on infected machines. This command is either executed by a computer user (which should flag a warning in the management software) or it's executed by a virus with admin permissions that went undetected by the antivirus solution on the machine. The stakes are low enough and the vendor is irresponsible enough that I don't see a problem with publishing a PoC when vendors lie about these kinds of bugs.
Of course remote exploitation and auth bypass PoCs shouldn't be released into the wild without trying to get a patch out first, but even still vendors like D-Link just don't seem to care if you don't at least threaten them with releasing the details to the public.
If one publicly discloses some mitigation it's usually enough to give malicious actors enough to go on anyway.
If vendor denies there is a problem despite repeated submissions of evidence then customers are already at risk indefinitely.
They were already at risk and didn't even know before disclosure. If anyone's to blame for anything, it's the corporation. They were told a vulnerability existed. If it got to the point people are releasing things to the public, it's certainly because they neglected to do what needed to be done.
Yes, we're all arguing in favor of responsible disclosure, but if the vendor is not communicating in good faith, what else can you do?
Under those circumstances? Yes. How else would I learn that my systems are vulnerable?
Always assume a bad guy has the 0-day before a security researcher.