3 ms·

>Such a move is typically seen as a no-no by the infosec community, which favors transparency. Transparency, sure, but since when do we release CVE details bef

by _cenw 3y ago

>Such a move is typically seen as a no-no by the infosec community, which favors transparency. Transparency, sure, but since when do we release CVE details before a patch? Even in open source projects, there often is only an announcement that there will be an important patch, and the writeup / CVE content is at earliest published the day after the patch is available. Giving some notice on a closed source product seems even more sensible because it's much harder to extract a vulnerability from a point release.

gurchik 3y ago
Rapid7's article on the topic[1] mostly focuses on the need for providing enough information to IT admins so they can understand the severity of the problem. There are other unsaid reasons for this (credit/payment I'd imagine is part of it), but on face value doesn't this make sense? When Metabase[2] says "Upgrade your instance NOW" and they have a vuln that "allows unprivileged access to any Metabase instance" I upgraded immediately. When JetBrains[3] says "4 security problems have been fixed. We highly recommend installing this update as it includes a fix for a critical security vulnerability" then many people are not going to upgrade as quickly. Jetbrains eventually gave more information[4] but would they have done this if Rapid7 wasn't threatening to disclose it themselves? ^1: https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-of-silent-patches/ https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-... ^2: https://discourse.metabase.com/t/upgrade-your-metabase-instance-now/26062 https://discourse.metabase.com/t/upgrade-your-metabase-insta... ^3: https://www.jetbrains.com/help/teamcity/teamcity-2023-11-4-release-notes.html#Security https://www.jetbrains.com/help/teamcity/teamcity-2023-11-4-r... ^4: https://blog.jetbrains.com/teamcity/2024/03/additional-critical-security-issues-affecting-teamcity-on-premises-cve-2024-27198-and-cve-2024-27199-update-to-2023-11-4-now/ https://blog.jetbrains.com/teamcity/2024/03/additional-criti...
- lolinder 3y ago
  This is a decent explanation for issuing a CVE and a clear disclosure immediately after a patch is available, but the claim in the article is that best practice is to reveal immediately regardless of whether there's a patch. That makes no sense to me.
  - ziddoap 3y ago
    You can read their actual disclosure policy here: https://www.rapid7.com/security/disclosure/ https://www.rapid7.com/security/disclosure/ They do not -- and the industry as a whole does not -- claim that that the best practice is to immediately reveal a vulnerability regardless of a patch.
    - lolinder 3y ago
      Thanks. That makes a lot more sense. The Register must have misinterpreted the controversy when they wrote this: > 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, which favors transparency, but there's apparently a time and a place for these things.
      - ziddoap 3y ago
        Yes, this article is unfortunately disappointing and seems to have a bit of spin put on it, considering this is all pretty standard coordinated disclosure stuff.
taviso 3y ago
The issue here is that the vendor did release patches, but then tried to hide that they fixed a vulnerability. This is usually called "silent patching", and it's controversial. As with any disclosure discussion, there are lots of opinions here and everyone likes to call everyone else irresponsible. If you're pro-silent patching, you might argue that it reduces the number of people who know about a vulnerability, so publishing advisories is irresponsible. If you're anti-silent patching, you might argue that it reveals the vulnerability to the people who monitor patches without giving any warning to the affected users that they need to patch, so not publishing advisories is irresponsible. Maybe you're just a "minimum details" kind of person, and providing full details is irresponsible. Or maybe you're a "full details" kind of person, and restricting security professionals from accessing the information they need to do their jobs is irresponsible. In summary, I'm irresponsible for leaving this comment and you're irresponsible for reading it.
- _cenw 3y ago
  This feels like two useless extremes. Enough information to give an idea of severity / class of vulnerability with the patch itself and the writeup a week later when everyone has had a chance to patch and those skilled hackers Rapid7 cites have disseminated the bug from the release diff.
  - deleted 3y ago
    [deleted]
bitexploder 3y ago
They stopped communicating with Rapid7. When you stop, you know, coordinating with the researchers they are free to do what they want. Rapid7 likely gave them their entire process, set expectations and coordinated with JetBrains up front. This is sort of an “ethical standard” most firms and security researchers follow. The timeline’s they use and the exact process they follow varies. The key goal is to keep the vulnerabilities public and properly credit the researchers. Coordinated disclosure is an olive branch, so you know exactly what to expect and how to behave. It is generally very reasonable. If you break the terms or spirit of this process the researchers have no reason or real recourse but to release their info whenever they want and feel is appropriate. Don’t break the faith, the researchers are essentially doing you a favor by following this policy. It really is not hard to communicate and act in good faith on both sides. I have coordinated the release of dozens of vulnerabilities. I have definitely disclosed them after companies ghosted us or threatened us hoping to make the issue go away. JetBrains got cute and cut the researchers out of the loop. Now future researchers will likely treat JetBrains as a bad faith actor and proceed accordingly.
- _cenw 3y ago
  I've done responsible disclosure myself. But I wouldn't dunk on a vendor for not telling me they released a fix on the same day because I'd probably just assume it's internal communication issues. And then attribute their late publishing of associated CVEs to my threats. It all feels a bit petty and rushed (to get the credit?) to me. Especially if a fix it cut into a regular release and not a hotfix, it likely just made it in by accident.
  - bitexploder 3y ago
    I would reserve judgment until seeing everything. I am just advocating from the general perspective of a security firm. I ran one for a decade and disclosed a lot of vulns. My experience was almost always that vendors were the ones creating issues. We tried our best due to how sensitive issues can be and viewed each vendor or company as a potential customer. Rapid7 could have easily been rude or unreasonable, but that is not the norm for sure. It probably was a little petty, but we don’t know what the lead up was either. You just get tired of being jerked around as a security firm when you do this a lot.

by _cenw 3y ago

gurchik 3y ago

Rapid7's article on the topic[1] mostly focuses on the need for providing enough information to IT admins so they can understand the severity of the problem. There are other unsaid reasons for this (credit/payment I'd imagine is part of it), but on face value doesn't this make sense? When Metabase[2] says "Upgrade your instance NOW" and they have a vuln that "allows unprivileged access to any Metabase instance" I upgraded immediately. When JetBrains[3] says "4 security problems have been fixed. We highly recommend installing this update as it includes a fix for a critical security vulnerability" then many people are not going to upgrade as quickly. Jetbrains eventually gave more information[4] but would they have done this if Rapid7 wasn't threatening to disclose it themselves? ^1: https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-of-silent-patches/ https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-... ^2: https://discourse.metabase.com/t/upgrade-your-metabase-instance-now/26062 https://discourse.metabase.com/t/upgrade-your-metabase-insta... ^3: https://www.jetbrains.com/help/teamcity/teamcity-2023-11-4-release-notes.html#Security https://www.jetbrains.com/help/teamcity/teamcity-2023-11-4-r... ^4: https://blog.jetbrains.com/teamcity/2024/03/additional-critical-security-issues-affecting-teamcity-on-premises-cve-2024-27198-and-cve-2024-27199-update-to-2023-11-4-now/ https://blog.jetbrains.com/teamcity/2024/03/additional-criti...

lolinder 3y ago
This is a decent explanation for issuing a CVE and a clear disclosure immediately after a patch is available, but the claim in the article is that best practice is to reveal immediately regardless of whether there's a patch. That makes no sense to me.
- ziddoap 3y ago
  You can read their actual disclosure policy here: https://www.rapid7.com/security/disclosure/ https://www.rapid7.com/security/disclosure/ They do not -- and the industry as a whole does not -- claim that that the best practice is to immediately reveal a vulnerability regardless of a patch.
  - lolinder 3y ago
    Thanks. That makes a lot more sense. The Register must have misinterpreted the controversy when they wrote this: > 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, which favors transparency, but there's apparently a time and a place for these things.
    - ziddoap 3y ago
      Yes, this article is unfortunately disappointing and seems to have a bit of spin put on it, considering this is all pretty standard coordinated disclosure stuff.

taviso 3y ago

The issue here is that the vendor did release patches, but then tried to hide that they fixed a vulnerability. This is usually called "silent patching", and it's controversial. As with any disclosure discussion, there are lots of opinions here and everyone likes to call everyone else irresponsible. If you're pro-silent patching, you might argue that it reduces the number of people who know about a vulnerability, so publishing advisories is irresponsible. If you're anti-silent patching, you might argue that it reveals the vulnerability to the people who monitor patches without giving any warning to the affected users that they need to patch, so not publishing advisories is irresponsible. Maybe you're just a "minimum details" kind of person, and providing full details is irresponsible. Or maybe you're a "full details" kind of person, and restricting security professionals from accessing the information they need to do their jobs is irresponsible. In summary, I'm irresponsible for leaving this comment and you're irresponsible for reading it.

_cenw 3y ago
This feels like two useless extremes. Enough information to give an idea of severity / class of vulnerability with the patch itself and the writeup a week later when everyone has had a chance to patch and those skilled hackers Rapid7 cites have disseminated the bug from the release diff.
- deleted 3y ago
  [deleted]

bitexploder 3y ago

They stopped communicating with Rapid7. When you stop, you know, coordinating with the researchers they are free to do what they want. Rapid7 likely gave them their entire process, set expectations and coordinated with JetBrains up front. This is sort of an “ethical standard” most firms and security researchers follow. The timeline’s they use and the exact process they follow varies. The key goal is to keep the vulnerabilities public and properly credit the researchers. Coordinated disclosure is an olive branch, so you know exactly what to expect and how to behave. It is generally very reasonable. If you break the terms or spirit of this process the researchers have no reason or real recourse but to release their info whenever they want and feel is appropriate. Don’t break the faith, the researchers are essentially doing you a favor by following this policy. It really is not hard to communicate and act in good faith on both sides. I have coordinated the release of dozens of vulnerabilities. I have definitely disclosed them after companies ghosted us or threatened us hoping to make the issue go away. JetBrains got cute and cut the researchers out of the loop. Now future researchers will likely treat JetBrains as a bad faith actor and proceed accordingly.

_cenw 3y ago
I've done responsible disclosure myself. But I wouldn't dunk on a vendor for not telling me they released a fix on the same day because I'd probably just assume it's internal communication issues. And then attribute their late publishing of associated CVEs to my threats. It all feels a bit petty and rushed (to get the credit?) to me. Especially if a fix it cut into a regular release and not a hotfix, it likely just made it in by accident.
- bitexploder 3y ago
  I would reserve judgment until seeing everything. I am just advocating from the general perspective of a security firm. I ran one for a decade and disclosed a lot of vulns. My experience was almost always that vendors were the ones creating issues. We tried our best due to how sensitive issues can be and viewed each vendor or company as a potential customer. Rapid7 could have easily been rude or unreasonable, but that is not the norm for sure. It probably was a little petty, but we don’t know what the lead up was either. You just get tired of being jerked around as a security firm when you do this a lot.