3 ms·

"Rapid7 says it reported the two TeamCity vulnerabilities in mid-February, claiming JetBrains soon after suggested releasing patches for the flaws before public

"Rapid7 says it reported the two TeamCity vulnerabilities in mid-February, claiming JetBrains soon after suggested releasing patches for the flaws before publicly disclosing them. Such a move is typically seen as a no-no by the infosec community,..." As far as I am aware the majority of the infosec community would prefer to release a patch before releasing a security issue, but what do I know...

TheGeminon 3y ago
The ideal way is to release a security advisory that some CVE patches are coming with no details, so that upgrades can be prepped coordinated for a known patch day.
c2h5oh 3y ago
The common practice is to hold off disclosure until a patch is ready and has been tested, that way competent organizations will be able to jump on the problem and patch ASAP. If you release a patch without disclosure there is a good chance many competent organizations will hold off applying it waiting for others to be the canary. Releasing a patch and mentioning it fixes security issues while delaying vulnerability details is not much better - malicious actors with enough resources will figure out what has been changed and where the problem is. At the same time there will be a strong incentive to downplay the severity.
bitexploder 3y ago
The issue is JetBrains was trying to avoid having the issues disclosed, or at least significantly delay it. They would have been communicated an explicit timeline and Rapid7s entire process up front. Rapid7 would have let them patch and released the vulnerability details on a generous timeline if JetBrains had continued to communicate with Rapid7. The reason Rapid7 is doing this is because there are so many companies out there that will ghost you and ignore that your firm exists trying to delay the release of your vulns indefinitely. I have released vulns at my company and coordinated dozens of them. Before coordinated disclosure was a thing it was the wild west and companies often did shady things expecting they could muscle or ignore security researchers.

TheGeminon 3y ago

The ideal way is to release a security advisory that some CVE patches are coming with no details, so that upgrades can be prepped coordinated for a known patch day.

c2h5oh 3y ago

The common practice is to hold off disclosure until a patch is ready and has been tested, that way competent organizations will be able to jump on the problem and patch ASAP. If you release a patch without disclosure there is a good chance many competent organizations will hold off applying it waiting for others to be the canary. Releasing a patch and mentioning it fixes security issues while delaying vulnerability details is not much better - malicious actors with enough resources will figure out what has been changed and where the problem is. At the same time there will be a strong incentive to downplay the severity.

bitexploder 3y ago

The issue is JetBrains was trying to avoid having the issues disclosed, or at least significantly delay it. They would have been communicated an explicit timeline and Rapid7s entire process up front. Rapid7 would have let them patch and released the vulnerability details on a generous timeline if JetBrains had continued to communicate with Rapid7. The reason Rapid7 is doing this is because there are so many companies out there that will ghost you and ignore that your firm exists trying to delay the release of your vulns indefinitely. I have released vulns at my company and coordinated dozens of them. Before coordinated disclosure was a thing it was the wild west and companies often did shady things expecting they could muscle or ignore security researchers.