3 ms·

I think this approach exposes a number of problems that are pretty relevant. First off vendors by decrypting the content of the researcher's submission are bas

by snagg 16y ago

I think this approach exposes a number of problems that are pretty relevant. First off vendors by decrypting the content of the researcher's submission are basically giving up vulnerabilities to the bad guys that want to target unpatched systems (read: what malware most of the time does). Second thing I see no reasons why the vulnerability disclosure process should change and migrate to SSL based encryption: vendors can already expose "lies" if they feel like it with PGP encryption and honestly having a "middle-man" in between that can potentially have sensible data looks like a bad idea. So how about: researchers post on the website the SHA-1 of the POC or just a line saying "product X is vulnerable", then the owner of the website asks the vendor for confirmation. If the researcher has no "karma points" then the submission is hold back until the vendor confirms, if the researcher has "karma points" (already multiple confirmed and valuable submissions) then the advisory gets published immediately regardless of whether the vendor acknowledges it or not. Still does it actually help anybody? how would you convince consumers to actually pick products or similar based on that website? To me it looks like the people interested in this kind of information have already other means (twitter, ml, direct contact with vendors), the others don't care.

zedshaw 16y ago
> First off vendors by decrypting the content of the researcher's submission are basically giving up vulnerabilities to the bad guys that want to target unpatched systems They already do this. After a vulnerability is patched and fixed they release what it did. > Second thing I see no reasons why the vulnerability disclosure process should change and migrate to SSL based encryption It's a proposed first step, and makes sure that no vendor can avoid the system by simply not publishing a key. I envision in the future their GPG key would also be on the site and could be used. > vendors can already expose "lies" if they feel like it with PGP encryption and honestly having a "middle-man" in between that can potentially have sensible data looks like a bad idea. 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. Finally, your proposed karma points system doesn't seem to solve anything. If everything is encrypted so that the receiver is only able to decrypt (not even the sender can do that), then there's no point in preventing people from publishing. Are you afraid that someone would slander a company? Couldn't the company simply decrypt and publish their lies then sue them for slander?
- 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.

by snagg 16y ago

zedshaw 16y ago

> First off vendors by decrypting the content of the researcher's submission are basically giving up vulnerabilities to the bad guys that want to target unpatched systems They already do this. After a vulnerability is patched and fixed they release what it did. > Second thing I see no reasons why the vulnerability disclosure process should change and migrate to SSL based encryption It's a proposed first step, and makes sure that no vendor can avoid the system by simply not publishing a key. I envision in the future their GPG key would also be on the site and could be used. > vendors can already expose "lies" if they feel like it with PGP encryption and honestly having a "middle-man" in between that can potentially have sensible data looks like a bad idea. 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. Finally, your proposed karma points system doesn't seem to solve anything. If everything is encrypted so that the receiver is only able to decrypt (not even the sender can do that), then there's no point in preventing people from publishing. Are you afraid that someone would slander a company? Couldn't the company simply decrypt and publish their lies then sue them for slander?

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.