Comment by zedshaw | Hacker News Reader

Comment by zedshaw | Hacker News Reader

Parent Full thread

> 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?

> 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.

> 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.

>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.

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?

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?

Reply on news.ycombinator.com