331–340 of 359 posts
> "we are letting the public know of these flaws but we are not putting out technical details and have no intention of putting out technical details, ever"
It's always a risk, because now people know where to look to recreate it themselves, it's not like this is a full-disclosure release where you're SOL as a manufacturer and have to race rampant public exploitation.
Earlier quoted context omitted.
I understand what you are OK with. I am saying that I believe, from a fairly long scope of interaction, you are a better person than that. They've disseminated widely an attack strategy to people who didn't have it. Nobody except AMD can fix the problem, regardless of the good intentions of other actors--on the other hand, many bad actors can use that information. That's as shoot-the-hostages as it gets. Security res…
I strongly disagree with the reasoning you're using here. The premise of your argument is that without vendor cooperation, end-users are helpless to mitigate the impact of security flaws. No, they aren't. Not only are they not helpless, but many of them are in fact ethically obligated to mitigate exposures with or without the assistance of their vendors. Almost every end user has at least one last-resort mitigation f…
So if a hospital runs a life support on a vulnerable chip, they should just hit the power switch until it's fixed.
Or what about a computer controlling a nuclear power plant? An airplane? Spacecraft or Satellite?
Vulnerabilities don't restrict themselves to equipment that is non-essential for people to survive or would cost millions to replace in consequence of a hack or shutdown (please try to revive a sat after you did a full shutdown, I will be awaiting your report on how you'll align the antenna)
Earlier quoted context omitted.
First hit for googling "Spectre Javascript POC": https://github.com/ascendr/spectre-chrome
> Enable `#shared-array-buffer` in `chrome:///flags` under your own risk...
Earlier quoted context omitted.
Then you were wrong, since those attacks against unpatched, unhardened hosts are trivially weaponizable through browser Javascript.
They're weaponizable when using a small and rapidly shrinking percentage of unpatched browsers running JavaScript delivered by extremely uncommon websites.
All it takes it emailing them a slightly convincing link, and they're running javascript from one of those "extremely uncommon websites". It doesn't matter how common the website it, a single website can compromise millions of users.
Earlier quoted context omitted.
Close to 100% of software has bugs. Almost all drivers have bugs. Anything that prioritises company profit and release dates over complete correctness in sectors where bugs == deaths, will have bugs. (And even those sectors are not magically immune) So yes - I expect they do.
So are vendors who release buggy drivers not "dicks" for the same reason that chip manufacturers aren't?
Exceptions: issue was known but got ignored due to release schedule, or security was never mentioned in the project and at no level was there any security consideration. But that's for specific management issues, not engineers or the vendor in general.
Earlier quoted context omitted.
3. The vulnerabilities are minor, barely worse than normal expected behaviour; just enough to call them vulnerabilities. All these "exploits" consist of using ultra-privileged access (signed device drivers, or flashing the BIOS) for bad purposes. In the white paper, many attacks are hypothetical and many phrases are vague and slippery, suggesting the "researchers" barely achieved execution of something, not real payl…
Pwn2own, iOS jailbreaking, and Playstation hacking have shown time and time again that chaining up seemingly innocuous exploits to get to the stage where you can run a "minor exploit which requires ultra-privileged access" is definitely within the reach of bored/smart teenagers with no more motivation than a new laptop or gaining the ability to pirate or cheat at games... Suggesting this is "just hypothetical" becaus…
Earlier quoted context omitted.
> until AMD authorizes publication AMD doesn't have the power to prevent publication of research from third party researchers that haven't entered in an agreement with them. This definitely isn't insider trading.
> AMD doesn't have the power to prevent publication of research from third party researchers that haven't entered in an agreement with them. This definitely isn't insider trading. Correct, though this assumes AMD has yet to reply. If AMD did reply after the initial disclosure and before any trades were made, then the order of events which may warrant such a look would be: - Private Disclosure made. - AMD replies priv…
Earlier quoted context omitted.
Responsible disclosure is an Orwellian term literally coined by vendors as a way to coerce researchers into adhering to vendor schedules and vendor PR plans. https://hn.algolia.com/?query=author:tptacek%20responsible%2...
Btw, your HN search result page links to all of the references that you THINK what the term "Responsible disclosure" means. Be it "coordinated disclosure" or whatever else, I don't care. But I don't think it's ethical to disclosure the security vulnerabilities to the wild without contacting the vendor and given them a timeline (should be MUCH LONGER than 24 hours) and the benefit of doubt first. Hypothetically speaki…
Vendors who wish to discourage that behavior could offer comparably-large bug bounties instead. And, of course, make their products more secure in the first place.
Earlier quoted context omitted.
So are vendors who release buggy drivers not "dicks" for the same reason that chip manufacturers aren't?
Unless they released it maliciously, I don't hold it against them. And wouldn't call anyone a dick unless they planned to do something evil. Exceptions: issue was known but got ignored due to release schedule, or security was never mentioned in the project and at no level was there any security consideration. But that's for specific management issues, not engineers or the vendor in general.
Earlier quoted context omitted.
People who work in vulnerability research generally just point and laugh at him. His opinion on this doesn't matter.
And the people who focus on real security point and laugh at the so called "vulnerability research engineers", and agree with Linus point.