[anonymouzz]

What bothers me is that they did not responsibly disclose the vulnerabilities to the manufacturers ahead of time. This is not moral, and I'm not sure what one gains by not doing that. I think that conference organizers should pressure presenters to do that before talks.

Either that or attendees should apply bottom up pressure and ask live questions like "what did you do to responsibly disclose this issue?". I think I'll do that on future security conferences I attend.

[Canada]

I wish the everyone would stop using the term "responsible" to describe "coordinated" disclosure. Researchers do not owe vendors any cooperation at all. It is perfectly moral to present factual information without any notice whatsoever. I think there's often something to gain through coordinated disclosure, but not always, and it's not your choice to make unless we're talking about your own findings.

[32032141]

Agreed. Researchers owe the companies absolutely nothing.

[anonymouzz]

It's not about the companies. I do not care much about them.

It's about people that may be hacked between someone's 0day disclosure and manufacturer's response. And if the manufacturer doesn't care to fix the bug - roast them about that. It's their fault.

It's not moral because people (not companies) may suffer. Your actions have consequences.

[jstanley]

The vulnerability doesn't pop into existence the second it is publicly announced. It was already there. Everybody was already vulnerable.

At least if it's publicly announced people can take steps to defend against it.

[anonymouzz]

Yes but why not send a single email to the manufacturer before making it public? Does it really hurt so much?

From a "cyberpunk hacker" mentality this only gives you an opportunity to roast the manufacturer if they do nothing. Perhaps even bankrupt them, I don't care. Competition will take their places and hopefully be better.

[tgsovlerkhgsel]

> Does it really hurt so much?

Potentially yes. The manufacturer may attempt to prevent publication through legal threats or action, which can be annoying and expensive even if you ultimately win. The incentive to be annoying goes down significantly once the disclosure cannot be prevented (because it's already public) and the public is watching (i.e. any action against the researcher has a higher likelihood of public backlash).

It also allows the manufacturer, who is likely more experienced and has more resources, to start PR to downplay the attack.

I generally default to responsible/coordinated disclosure, but I also do my research first. If the company has previously shown undesirable behavior (like the stuff I've described), or I've reported to them previously and didn't like the experience, they'll learn about the disclosure from the news.

[cdoxsey]

That doesn't mean hackers knew about it.

It's like finding out my neighbor doesn't lock his front door at night and announcing it on twitter. I didn't create the vulnerability but I'm helping criminals take advantage of it.

[edmccard]

>It's like finding out my neighbor doesn't lock his front door at night and announcing it on twitter.

No, it's like finding out your neighbor sold a bunch of faulty locks to a bunch of other people. There's a difference between information that would benefit only one person (the neighbor in your analogy) and information that would benefit many people (the neighbor's customers in my analogy)

[32032141]

It's not the researchers responsibly that a vendor is incompetent, frankly. The vendor released something broken, that's their burden to bear, it's not wise to assume that you're the first to find a bug, with that in mind expedient full disclosure is acting with the customers best interests.

[32032141]

I've been doing security research in this industry for a while and it's effectively not worth anybodies time to attempt to report hardware wallet, or software bugs 'responsibly'. I've found that by far the most common responses are being told that the attack doesn't fit into their design (as here), it's not reasonable to expect, or that for some reason. For a long time the Trezor wallets custom crypto library was simply python transliterated and had a sidechannel attack so large that you could measure the EC multiply operation with a SDR from across a room. This was supposedly out of their scope (but has been since somewhat fixed, but not entirely) for some reason, despite being something that is easily fixed using industry standard constant time operations.

Responses you do get at protecting the fact that a lot of the bugs are burned into hardware and can't be fixed by anything but them re-issuing it. It's not in the interests to ever acknowledge issues.

[wbl]

Power analysis is a lot harder to fix then you think. Constant time isn't enough: you probably need blinding and some hardware assistance with features that are inevitably under NDA.

[32032141]

This is true. Many of these devices are using effectively joke crypto libraries however, theres a world of difference between something that needs a sophisticated setup, and the python crypto library that was transliterated into C and makes absolutely no effort at being constant time. The original Trezor software took something in the order of 300ms to produce a single signature. You could probably have done recovery of the nonce from ec multiply with a stopwatch.

If your security appliance is using an ECDSA library for Arduino that has absolutely zero tests or review, you just outright lost. Some of the more well known products in the space do exactly this.

https://github.com/kmackay/micro-ecc/blob/master/test/test_e...