Comment by cantrevealname | Hacker News Reader

Comment by cantrevealname | Hacker News Reader

Parent Full thread

I think the author brings up a good point about so-called "responsible disclosure" (a self-serving term by the vendors).

I'm paraphrasing his 3 reasons for disclosing immediately:

1. It's unacceptable to wait half a year until a vulnerability is patched.

2. Bug bounties are riddled with tricks to delay you, shenanigans as to whether they'll pay you or not, and games to low ball the price.

3. It's arrogant to wait months while meanwhile preparing for a big boastful disclosure.

I'm thinking that we could add to this list as follows:

4. The vulnerability might already be well-known and being used by black hats and secret government agencies. Releasing the details immediately puts all of us on an equal footing.

5. Punish the vendors for having such awful security. Just the other day, HN had an article[1] about Crucial SSDs that encrypt the drive with a key that doesn't depend on the password; you can decrypt the drive without the password just by patching the firmware. Is Crucial going to get punished for such an outrageous lie about their encryption? The marketplace mechanisms that force vendors to pay proper attention to security are trust in the brand, independent security reviews (thank you security researchers!), government regulation (no thank you), and immediately naming and shaming them without giving them time to cover it up or downplay it.

6. Punish the users for not demanding higher security. Of course, we could suffer as result, but it's not the security researcher who caused the bug and it's not the security researcher who would be exploiting it. There needs to be demand from users for higher security in their purchases.

7. We get to see all the details if the vulnerability is disclosed immediately. If the vulnerability is disclosed after "responsible disclosure", plenty of times you don't get the raw details. I wouldn't be surprised if many security researchers are signed to NDAs (or simply threatened by lawyers), so we don't hear about the bugs at all. Having the full details published immediately advances our knowledge in the security field more than a partial disclosure months later (or a non-disclosure).

[1] https://news.ycombinator.com/item?id=18382975

I agree, except for the notion of security “research” being a significant market factor.

The marketplace gives very few shits about security vulnerabilities, despite the constant stream of outrageous defects. The real market force is selling consulting and security gizmos imo. Nobody is ditching peoplesoft because it’s a a security disaster — they double down and buy accessories to secure it.

Big companies like Microsoft got security religion when the prospect of liability started becoming real, particularly when Blaster/Welchia paralyzed big networks in the 2000s.

The author's reasons are specific to Oracle. I believe other vendors have shown themselves to be worthy of the trust required to for such cooperative disclosure schemes to work.

As to your own more general arguments, they lead me to believe you're somewhat manichaean, and possibly a bit too eager to assign guilt and follow up with punishment.

Specifically, punishing users for "not demanding higher security" is a suggestion that can only be made when the metric ("high security") has become an objective by itself, completely divorced from real-world outcome that spawned it, namely to avoid people being harmed.

It's unclear if punishing users could reliably work as a proxy to get vendors to increase security. Thus, it is already assured that there will be some users that will be harmed by your idea with no positive effect possibly justifying that harm.

If, however, the mechanism works as envisioned by you, it would work just as well without helping it along: the very same effect will occur organically, whenever insecurity results in harm. And where it doesn't, nothing is lost. Quite the opposite: insecurity that does not result in harm is quite obviously something good.

It's a well-known failure mode of the human mind to so fully engage with some intermediate task that one forgets the initial motivation. Hence police officers arresting 6-year olds and soldiers "just following orders". Here, your suggestion is the result of fetishising one specific quality of software, namely security. Secure software, created in a process so beautiful it is a piece of art by itself, does not only shed its initial justification: Its pursuit suddenly legitimises actions specifically intended to injure those you once set out to protect.

Yeah, plus, you know: that mechanism assumes that fast disclosure harms users. So you're kinda contradicting all those other points about fast disclosure being helpful.

As to (5): You're not giving any reasons why early disclosure would result in more harm to the vendor, except for the very idea of responsible disclosure itself, namely lowering real-world harm by having a patch or other mitigation ready at the moment of disclosure. Here, you are falling into the same trap of being more interested in vengeance than justice, much like the first officer arriving at the crime scene putting another bullet in the victim to ensure that horrible criminal will face trial for murder, and not just assault.

yep, all of that is equivalent to "security by obscurity". Hiding vulnerabilities longer is of no use, it just helps companies to be ready to answer customers, not to fix things in a better way.

Also it's really unfair to most vendors that don't have close ties with the creator of the security problem. E.g. in the case of Intel this turned out really bad for all other OSs except Windows and Linux. On the other hand it makes using products/software from entities who continue with this policy even more unattractive.

In this case there is an easy mitigation for people aware of the vulnerability (change virtual network adapter), and of course they have to run a malicious guest to start with. I'm not sure this argument holds up as well if this were an RCE in an unauthenticated network service that can't be mitigated.

While you raise very good points overall, this one I have beef with:

>SSDs that encrypt the drive with a key that doesn't depend on the password

AFAIK, this is the standard practice in software harddrive/filesystem encryption - LUKS, TrueCrypt, etc., for practical reasons, and with no negative impact on security if properly implemented. AFAIK again, this is also how Firefox handles encryption of stored website login/password credentials - they are always encrypted using locally generated & held key; in case user supplies her own password, this key is encrypted with that password, with no change to the actual login/password store.

Contrast the following two scenarios:

- derive encryption key from user-supplied password [potentially weak key]

- encrypt the whole device / filesystem with the key [very long process, prone to interruption]

- user wishes to change the password

- re-encrypt the whole device / filesystem with the new key [very long process, prone to interruption]

vs.

- generate a cryptographically secure random or pseudorandom key

- store the password in device

- encrypt device with the key from the first write onward

- when user sets password, encrypt the stored key [no change to content of device necessary]

- from that point the user password is necessary to use the decryption/encryption key

- when the user changes password, re-encrypt the stored key only [no change to content of device necessary]

The second scenario is also more amenable to implementing various multi-password schemes, password-recovery techniques, and encryption secured with both passwords and hardware tokens.

The difference is that the key was not encrypted with the password.

If the key were properly encrypted (as you describe) the password check could not have been bypassed.

> You wrote: user supplies her own password, this key is encrypted with that password

The critical point you're missing is that the Crucial SSD was not doing that step. If the key doesn't depend on the password, then the raw key has to exist somewhere on the Crucial hard drive or in its firmware, so the task becomes an easy hunt for the key with a debugger. No password cracking required.

Reply on news.ycombinator.com