4 ms·

> They already do this. After a vulnerability is patched and fixed they release what it did. Usually researchers' submissions are way more detailed than the ad

by snagg 16y ago

> They already do this. After a vulnerability is patched and fixed they release what it did. Usually researchers' submissions are way more detailed than the advisories you see from vendors. Meaning that you cannot just decrypt the content of what the research submitted. It's true that oftentimes you can find the bug by reading the advisory and using tools to diff the patch but it's a long shot compared to just publishing the original researcher's submission imo. >Uh, not sure what the "middle-man" is, but if you mean vulnarb.com then no, the point is that it's industry standard asymmetric crypto so I wouldn't know anything. In fact, I'd have incentive to not know anything so that I'm not getting sued. yep I meant vulnarb.com. I'm not saying that you have anything decrypted and ready to use, I'm saying that it's pointless to have another recipient for sensible data. Cause in the extreme scenario where the private key is stolen than it's just more attack surface to get to the submissions. If we assume that no leak of this sort happens, still what's the reason for a third party to have this sort of data compared to say sha-1 hash of the Poc? Actually my point about the karma system is that you can achieve the same goal you have in mind without needing any sort of data from the researcher other than "product X is vulnerable" and then the karma points will determine whether the researcher is reliable or not.

zedshaw 16y ago
> Actually my point about the karma system is that you can achieve the same goal you have in mind without needing any sort of data from the researcher other than "product X is vulnerable" and then the karma points will determine whether the researcher is reliable or not. No, that doesn't actually solve this problem because then it just turns into a he-said-she-said. Also, you seem to leave out that the company can decide to decrypt it or not. Hell, they might come to an agreement with the researcher to just have the researcher assert it's fixed and never decrypt it. Although, I think that it should be fully exposed so people can see how it's really done and there's incentive to really fix it, not half-ass fix it.
- snagg 16y ago
  >No, that doesn't actually solve this problem because then it just turns into a he-said-she-said. then I fail to understand what you plan to do with the encrypted stuff that you get from the researcher since the only one able to decrypt it would be the vendor. At that point the scenario is: researcher says this is vulnerable, vendor denies it, somebody needs to decrypt the content of what the researcher has sent to the vendor. In contrast what happens without having the encrypted content is: researcher says this is vulnerable, vendor denies it, the researcher can publish the un-encrypted original advisory on your website if he feels like it. Regardless the SSL trick is a nice one I just don't see the point of the third-party involved and I somewhat doubt that a website like this can be useful to the end-user or to put pressure on the vendor.
  - zedshaw 16y ago
    Let's try a few of your supposed scenarios: 1. Researcher posts it. 2. Vender pulls it down and looks at it, then says it's harmless or not an issue. 3. Researcher thinks it is, and since the vendor says it's not, the researcher posts a cleartext version for them. 4. If it really is, then the vendor should have paid attention. Next scenario (not sure why you can't think past solving these yourself): 1. Researcher posts bogus spam. 2. Vendor decrypts, sees that it's bogus spam. 3. Vendor posts the decrypted version and flags it as spam. 4. It gets taken down or ignored if it is, and researcher is blocked eventually. Next scenario: 1. Researcher posts a vulnerability. 2. Vendor fixes it but half-asses it. 3. Researcher tells them it's not fixed, they say yes it is. 4. Researcher calls their bluff and posts the original cleartext. 5. If it really is fixed, then no harm done. If it's not, then vender screwed up. Pretty much, in most of the situations you've envisioned, you've assumed that the communication is one-way from researcher->vendor. Is there a reason you assumed that vendors wouldn't be able to post their replies back or decrypt and post the decrypted vuln for others to see?
    - snagg 16y ago
      You are missing the point: is there anything of the above that can't be done without a third party having access to the encrypted content vs having a simple hash of the email/poc sent to the vendor?
- deleted 16y ago
  [deleted]

by snagg 16y ago

zedshaw 16y ago

> Actually my point about the karma system is that you can achieve the same goal you have in mind without needing any sort of data from the researcher other than "product X is vulnerable" and then the karma points will determine whether the researcher is reliable or not. No, that doesn't actually solve this problem because then it just turns into a he-said-she-said. Also, you seem to leave out that the company can decide to decrypt it or not. Hell, they might come to an agreement with the researcher to just have the researcher assert it's fixed and never decrypt it. Although, I think that it should be fully exposed so people can see how it's really done and there's incentive to really fix it, not half-ass fix it.

snagg 16y ago
>No, that doesn't actually solve this problem because then it just turns into a he-said-she-said. then I fail to understand what you plan to do with the encrypted stuff that you get from the researcher since the only one able to decrypt it would be the vendor. At that point the scenario is: researcher says this is vulnerable, vendor denies it, somebody needs to decrypt the content of what the researcher has sent to the vendor. In contrast what happens without having the encrypted content is: researcher says this is vulnerable, vendor denies it, the researcher can publish the un-encrypted original advisory on your website if he feels like it. Regardless the SSL trick is a nice one I just don't see the point of the third-party involved and I somewhat doubt that a website like this can be useful to the end-user or to put pressure on the vendor.
- zedshaw 16y ago
  Let's try a few of your supposed scenarios: 1. Researcher posts it. 2. Vender pulls it down and looks at it, then says it's harmless or not an issue. 3. Researcher thinks it is, and since the vendor says it's not, the researcher posts a cleartext version for them. 4. If it really is, then the vendor should have paid attention. Next scenario (not sure why you can't think past solving these yourself): 1. Researcher posts bogus spam. 2. Vendor decrypts, sees that it's bogus spam. 3. Vendor posts the decrypted version and flags it as spam. 4. It gets taken down or ignored if it is, and researcher is blocked eventually. Next scenario: 1. Researcher posts a vulnerability. 2. Vendor fixes it but half-asses it. 3. Researcher tells them it's not fixed, they say yes it is. 4. Researcher calls their bluff and posts the original cleartext. 5. If it really is fixed, then no harm done. If it's not, then vender screwed up. Pretty much, in most of the situations you've envisioned, you've assumed that the communication is one-way from researcher->vendor. Is there a reason you assumed that vendors wouldn't be able to post their replies back or decrypt and post the decrypted vuln for others to see?
  - snagg 16y ago
    You are missing the point: is there anything of the above that can't be done without a third party having access to the encrypted content vs having a simple hash of the email/poc sent to the vendor?
deleted 16y ago
[deleted]