4 ms·

How much notification did you give the developers before you disclosed? Did you enforce a timeline?

by bdelay 2y ago

metadat 2y ago
Warning shots across the bow in private are the polite and responsible way, but malicious actors don't typically extend such courtesies to their victims. As such, compared to the alternative (bad actors having even more time to leverage and amplify the information asymmetry), a timely public disclosure is preferable, even with some unfortunate and unavoidable fallout. Typically security researchers are reasonable and want to do the right thing with regard to responsible disclosure. On average, the "bigger party" inherently has more resources to respond compared to the reporter. This remains true even in open source software.
- tsimionescu 2y ago
  This is a pretty dangerous take. The reality is that the vast majority of security vulnerabilities in software are not actively exploited, beause no one knows about them. Unless you have proof of active exploitation, you are much more likely to hurt users by publicly disclosing a 0-day than by responsibly disclosing it to the developer and giving them a reasonable amount of time to come out with a patch. Even if the developers are acting badly. Making a vulnerability public is putting a target on every user, not on the developer.
  - wisemang 2y ago
    Your take is the dangerous one. I don’t disagree that > the vast majority of security vulnerabilities in software are not actively exploited However I’d say your explanation that it’s > because no one knows about them is not necessarily the reason why. If the vendor or developer isn’t fixing things, going public is the correct option. (I agree some lead time / attempt at coordinated disclosure is preferable here.)
    - tsimionescu 2y ago
      > (I agree some lead time / attempt at coordinated disclosure is preferable here.) Then I think we are in agreement overall. I took your initial comment to mean that as soon as you discover a vulnerability, you should make it public. If we agree that the process should always be to disclose it to the project, wait some amount of time, and only then make it public - then I think we are actually on the exact same page. Now, for the specific amount of time: ideally, you'd wait until the project has a patch available, if they are collaborating and prioritizing things appropriately. However, if they are dragging their feet and/or not even acknowledging that a fix is needed, then I also agree that you should set a fixed time as a last ditch attempt to get them to fix it (say, "2 weeks from today"), and then make it public as a 0-day.
      - wisemang 2y ago
        Indeed, we’re in agreement. Though I’d suggest a fixed disclosure timeframe at time of reporting. Maybe with an option to extend in cases where the fix is more complex than anticipated.
  - dgfitz 2y ago
    > Unless you have proof of active exploitation Wouldn’t a “good criminal” just exploit it forever without getting caught? Your timeline has no ceiling.
    - tsimionescu 2y ago
      My point is: if you found a vulnerability and know that it is actively being exploited (say, you find out through contacts, or see it on your own systems, or whatever), then I would agree that it is ethical to publicize it immediately, maybe without even giving the creators prior notice: the vulnerability is already known by at least some bad actors, and users should be made aware immediately and take action. However, if you don't know that it is being actively exploited, then the right course of action is to disclose it secretly to the creators, and work with them to coordinate on a timely patch before any public disclosure. Exactly how timely will depend on yours and their judgement of many factors. Even if the team is showing very bad judgement from your point of view, and acting dismissively; even if you have a history with them of doing this - you still owe it to the users of the code to at least try, and to at least give some unilateral but reasonable timeline in which you will disclose. Even if you don't want to do this free work, the alternative is not to publicly disclose: it's to do nothing. In general, the users are still safer with an unknown vulnerability than they are with a known one that the developers aren't fixing. You don't have any responsibility to waste your own time to try to work with disagreeable people, but you also don't have the right to put users at risk just because you found an issue.
- dcow 2y ago
  100% It’s unethical to users who are at risk to withhold critical information. If McDonalds had an e-coli outbreak and a keen doctor picked up on it you wouldn't withhold that information from the public while McD developed a nice pr-strategy and quietly waited for the storm to pass, would you? Why is security, which seriously is a public safety issue, any different?
  - dinosaurdynasty 2y ago
    It's different because bad actors can take advantage of the now-public information. The point of a disclosure window is to allow a fix before _all_ bad actors get access to the vulnerability.
    - dcow 2y ago
      And some may already be taking advantage. This is a perfect example where users are empowered to self mitigate. You’re relatively okay on private networks but definitely not on public networks. If I know when the bad actors know then I can e.g. not run qbittorrent at a coffee shop until it’s patched.
  - TeMPOraL 2y ago
    What about a pre-digital bank? If you came across knowledge of a security issue potentially allowing anyone to steal stuff from their vault, would you release that information to the public? Would everyone knowing how to break in make everyone's valuables safer? Medicine and biosafety are PvE. Cybersecurity is PvP.
0xsee4 2y ago
In total it was about 45 days or so from the initial conversation. I waited for a patched version to be released, because the next important milestone after that would be finished backports to older versions still in use, which is clearly going to take a long time as it is not being prioritized, so I wanted to inform users. Initially I had said 90 days from the initial report, but it seemed like they were expanding the work to fill that time. I asked a number of times for them to make a security advisory and got no answer. Some discussions on the repo showed they were considering this as a theoretical issue. Now it's CVE-2024-51774, which got assigned within 48 hours of disclosing.
- perching_aix 2y ago
  > Some discussions on the repo showed they were considering this as a theoretical issue. That's hilarious. It's all theoretical until it's getting exploited in the wild...
  - hsbauauvhabzb 2y ago
    Any proof that actually happened or you just wearing a tin foil hat? Crypto enforcement en masse matter, intercepting highly specific targets using BitTorrent does not.
    - tga_d 2y ago
      I feel as though there is a generational gap developing between people who do and do not remember how prolific Firesheep used to be.
    - perching_aix 2y ago
      I think a better question is: why are you looking for evidence (not proof!) on me for something you are supposing?
    - Jerrrrrrry 2y ago
      Lol wait til you get personally targeted by a 0'day in extremely popular software for that sentiment to make you look stupid both ways.

How much notification did you give the developers before you disclosed? Did you enforce a timeline?

by bdelay 2y ago

How much notification did you give the developers before you disclosed? Did you enforce a timeline?

Warning shots across the bow in private are the polite and responsible way, but malicious actors don't typically extend such courtesies to their victims. As such, compared to the alternative (bad actors having even more time to leverage and amplify the information asymmetry), a timely public disclosure is preferable, even with some unfortunate and unavoidable fallout. Typically security researchers are reasonable and want to do the right thing with regard to responsible disclosure. On average, the "bigger party" inherently has more resources to respond compared to the reporter. This remains true even in open source software.

tsimionescu 2y ago
This is a pretty dangerous take. The reality is that the vast majority of security vulnerabilities in software are not actively exploited, beause no one knows about them. Unless you have proof of active exploitation, you are much more likely to hurt users by publicly disclosing a 0-day than by responsibly disclosing it to the developer and giving them a reasonable amount of time to come out with a patch. Even if the developers are acting badly. Making a vulnerability public is putting a target on every user, not on the developer.
- wisemang 2y ago
  Your take is the dangerous one. I don’t disagree that > the vast majority of security vulnerabilities in software are not actively exploited However I’d say your explanation that it’s > because no one knows about them is not necessarily the reason why. If the vendor or developer isn’t fixing things, going public is the correct option. (I agree some lead time / attempt at coordinated disclosure is preferable here.)
  - tsimionescu 2y ago
    > (I agree some lead time / attempt at coordinated disclosure is preferable here.) Then I think we are in agreement overall. I took your initial comment to mean that as soon as you discover a vulnerability, you should make it public. If we agree that the process should always be to disclose it to the project, wait some amount of time, and only then make it public - then I think we are actually on the exact same page. Now, for the specific amount of time: ideally, you'd wait until the project has a patch available, if they are collaborating and prioritizing things appropriately. However, if they are dragging their feet and/or not even acknowledging that a fix is needed, then I also agree that you should set a fixed time as a last ditch attempt to get them to fix it (say, "2 weeks from today"), and then make it public as a 0-day.
    - wisemang 2y ago
      Indeed, we’re in agreement. Though I’d suggest a fixed disclosure timeframe at time of reporting. Maybe with an option to extend in cases where the fix is more complex than anticipated.
- dgfitz 2y ago
  > Unless you have proof of active exploitation Wouldn’t a “good criminal” just exploit it forever without getting caught? Your timeline has no ceiling.
  - tsimionescu 2y ago
    My point is: if you found a vulnerability and know that it is actively being exploited (say, you find out through contacts, or see it on your own systems, or whatever), then I would agree that it is ethical to publicize it immediately, maybe without even giving the creators prior notice: the vulnerability is already known by at least some bad actors, and users should be made aware immediately and take action. However, if you don't know that it is being actively exploited, then the right course of action is to disclose it secretly to the creators, and work with them to coordinate on a timely patch before any public disclosure. Exactly how timely will depend on yours and their judgement of many factors. Even if the team is showing very bad judgement from your point of view, and acting dismissively; even if you have a history with them of doing this - you still owe it to the users of the code to at least try, and to at least give some unilateral but reasonable timeline in which you will disclose. Even if you don't want to do this free work, the alternative is not to publicly disclose: it's to do nothing. In general, the users are still safer with an unknown vulnerability than they are with a known one that the developers aren't fixing. You don't have any responsibility to waste your own time to try to work with disagreeable people, but you also don't have the right to put users at risk just because you found an issue.
dcow 2y ago
100% It’s unethical to users who are at risk to withhold critical information. If McDonalds had an e-coli outbreak and a keen doctor picked up on it you wouldn't withhold that information from the public while McD developed a nice pr-strategy and quietly waited for the storm to pass, would you? Why is security, which seriously is a public safety issue, any different?
- dinosaurdynasty 2y ago
  It's different because bad actors can take advantage of the now-public information. The point of a disclosure window is to allow a fix before _all_ bad actors get access to the vulnerability.
  - dcow 2y ago
    And some may already be taking advantage. This is a perfect example where users are empowered to self mitigate. You’re relatively okay on private networks but definitely not on public networks. If I know when the bad actors know then I can e.g. not run qbittorrent at a coffee shop until it’s patched.
- TeMPOraL 2y ago
  What about a pre-digital bank? If you came across knowledge of a security issue potentially allowing anyone to steal stuff from their vault, would you release that information to the public? Would everyone knowing how to break in make everyone's valuables safer? Medicine and biosafety are PvE. Cybersecurity is PvP.

0xsee4 2y ago

In total it was about 45 days or so from the initial conversation. I waited for a patched version to be released, because the next important milestone after that would be finished backports to older versions still in use, which is clearly going to take a long time as it is not being prioritized, so I wanted to inform users. Initially I had said 90 days from the initial report, but it seemed like they were expanding the work to fill that time. I asked a number of times for them to make a security advisory and got no answer. Some discussions on the repo showed they were considering this as a theoretical issue. Now it's CVE-2024-51774, which got assigned within 48 hours of disclosing.

perching_aix 2y ago
> Some discussions on the repo showed they were considering this as a theoretical issue. That's hilarious. It's all theoretical until it's getting exploited in the wild...
- hsbauauvhabzb 2y ago
  Any proof that actually happened or you just wearing a tin foil hat? Crypto enforcement en masse matter, intercepting highly specific targets using BitTorrent does not.
  - tga_d 2y ago
    I feel as though there is a generational gap developing between people who do and do not remember how prolific Firesheep used to be.
  - perching_aix 2y ago
    I think a better question is: why are you looking for evidence (not proof!) on me for something you are supposing?
  - Jerrrrrrry 2y ago
    Lol wait til you get personally targeted by a 0'day in extremely popular software for that sentiment to make you look stupid both ways.