6 ms·
Security Researchers: Is this request-for-private-disclosure + "90-days before public" reasonable? It's a SEVERE issue, to my mind, and 90 days seems too long
by ncr100 3y ago
Security Researchers: Is this request-for-private-disclosure + "90-days before public" reasonable?
It's a SEVERE issue, to my mind, and 90 days seems too long to me.
- bawolff 3y agoWhether its reasonable is debatable, but that type of time frame is pretty normal for things that aren't being actively exploited. This situation is perhaps a little different as its not an accidental bug waiting to be discovered but an intentionally placed exploit. We know that a malicious person already knows about it.
- londons_explore 3y agoIf you were following Google Project Zero's policy (which many researchers do), any in-the-wild exploits would trigger an immediate reveal.
- larschdk 3y agoDetecting a security issue is one thing. Detecting a malicious payload is something completely different. The latter has intent to exploit and must be addressed immediately. The former has at least some chance of noone knowing about it.
- cjbprime 3y agoIn this particular case, there is a strong reason to expect exploitation in the wild to already be occurring (because it's an intentional backdoor) and this would change the risk calculus around disclosure timelines. But in the general case, it's normal for 90 days to be given for the coordinated patching of even very severe vulnerabilities -- you are giving time not just to the project maintainers, but to the users of the software to finish updating their systems to a new fixed release, before enough detail to easily weaponize the vulnerability is shared. Google Project Zero is an example of a team with many critical impact findings using a 90-day timeline.
- ang_cire 3y agoAs someone in security who doesn't work at a major place that get invited to the nice pre-notification notifications, I hate this practice. My customers and business are not any less important or valuable than anyone else's, and I should not be left being potentially exploited, and my customers harmed, for 90 more days while the big guys get to patch their systems (thinking of e.g. Log4J, where Amazon, Meta, Google, and others were told privately how to fix their systems, before others were even though the fix was simple). Likewise, as a customer I should get to know as soon as someone's software is found vulnerable, so I can then make the choice whether to continue to subject myself to the risk of continuing to use it until it gets patched.
- cjbprime 3y agoOpenSSL's "notification of an upcoming critical release" is public, not private. You do get to know that the vulnerability exists quickly, and you could choose to stop using OpenSSL altogether (among other mitigations) once that email goes out.
- sidewndr46 3y agoif your system has already been compromised at the root level, it does not matter in the least bit
- Thorrez 3y agoWell if you assume everyone has already been exploited, disclosing quickly vs slowly won't prevent that. Also, if something is being actively exploited, usually there's no or very little embargo.
- wyldberry 3y agoI empathize with this as I've been in the same boat, but all entities are not equal when performing triage.
- freedomben 3y ago
- sterlind 3y agoI think you have to take the credibility of the maintainer into account. If it's a large company, made of people with names and faces, with a lot to lose by hacking its users, they're unlikely to abuse private disclosure. If it's some tiny library, the maintainers might be in on it. Also, if there's evidence of exploitation in the wild, the embargo is a gift to the attacker. The existence of a vulnerability in that case should be announced, even if the specifics have to be kept under embargo.
- fmajid 3y agoIn this case the maintainer is the one who deliberately introduced the backdoor. As Andres Freund puts it deadpan, "Given the apparent upstream involvement I have not reported an upstream bug."
- decoy78 3y agoimho it depends on the vuln. I've given a vendor over a year, because it was a very low risk vuln. This isn't a vuln though - this is an attack.
- account42 3y ago> imho it depends on the vuln. I've given a vendor over a year, because it was a very low risk vuln. But why? A year is a ridiculous time for fixing a vulnerability even a minor one. If a vendor is taking that long its because they don't prioritize security at all and are just dragging their feet.
- sidewndr46 3y agoI've always laughed my ass off at the idea of a disclosure window. It takes less than a day to find RCE that grants root privileges on devices that I've bothered to look at. Why on earth would I bother spending months of my time trying to convince someone to fix something?
- BartjeD 3y agoThe fraudulent author must have enjoyed the 'in joke' -- He's the one create vulnerabilities..