I do not need to be a security researcher to understand that they, as with everyone else, have an obligation to the body politic to not be a dick (as in all things!). There are actors who may be aware of this attack already--but, as I mentioned elsethread, wider knowledge of attacks like this have a much higher chance of splashing back on end users who literally don't know any better than it does AMD. I mean, I couldn't give less of a shit about how AMD feels--they'll be fine regardless--but there are people downrange of this, not just some company.

This is shoot-the-hostages stuff, and I believe that you are better than to be OK with that.

This isn't "shoot the hostages". The researchers didn't manufacture the vulnerabilities; AMD did. If 4 dudes in a basement can find exploitable driver vulnerabilities, so can 10 researchers none of us will never have heard of working in a nondescript office somewhere in Bulgaria. The only moral differences is that these 4 dudes told us about what they found --- something else they had no actual obligation to do.

Again: it seems really likely that these vulnerabilities have been hyped way out of proportion to their real impact. I think it's reasonable to be irritated by that (again, though: this isn't a first). But other than that, I don't understand how people arrive at the conclusion that independent security researchers owe strangers the results of their work.

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 researchers owe "strangers" (which is a really weird term for "society at large" that I don't think you, specifically, would be using with such connotations outside of a security context where you'd already made a decision) the same courtesy they owe everyone else: to not endanger people unnecessarily. I agree with you that this is a relatively minor vulnerability, I'm not hyping it or anything--but it's still a vulnerability, it is still more widely known now, and there is a bigger pool of bad actors than there was last week able to use it against people, irrespective of AMD's stock price.

There's certainly a gray area, if a vendor hasn't acted to fix something you know they know about. I'm not talking about that. But 24 hours and briefing the media before letting AMD know, as it very much seems like they did, is well outside of what I could consider any reasonable gray area.

If you care about end users, and you should because they are your fellow people, you don't publicize how bad actors can hurt them. You just don't. It's just...minimal decency, to care about other people. I can't see it any other way.

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 for any vulnerability: the power switch.

Most of the time, most users have better non-patching mitigations than that. These vulnerabilities are all post-compromise privilege escalation flaws. Their exploitation is situational and most users can do things to eliminate the situation that enables their exploit.

You might not like the fact that end-users have to make hard, expensive choices about how to mitigate flaws. But if you think about it for just a second, you'll see that the idea that patches were saving them from this choice was fallacious. There is no reason to believe these 4 dudes were the only ones in the world capable of finding these flaws (the reality is that if they're the only ones who know about them, it's because the kinds of flaws they found simply aren't important enough to demand focused attention from others). All restricted disclosure does is prevent end users from making the choice for themselves.

I believe that as a general rule, we're better off when we have the most information available to us about vulnerabilities. Personally, I'd probably stop short of publishing exploit code. But other researchers that most of us respect a great deal in the abstract do not have that particular scruple, and some --- like the original Metasploit project --- made it a point to publish exploit code immediately, patch or no patch, to arm operators with information about their exposure.

This isn't an idle opinion. If there was working Usenet search in 2018, you could find me making approximately the same argument back in the 1990s, when I worked as a researcher at SNI, the world's first commercial vulnerability research lab.

I would say they are all invasive evil maid threat vectors. Each one requires either physical access to the hardware or (as you stated) an already established root privileges. We all know that if you have physical access to hardware, it's essentially game over.

However. One of the vulnerabilities supposedly allowed to subvert UEFI secure boot. If that's true and allows to boot arbitrary media, then the others are equally feasible, because an attacker can boot into a root shell of their choosing.

The timing in this disclosure reeks of malice, though. Giving a 24h advance warning basically allows the outfits to claim that they disclosed vulnerabilities to manufacturer before going public. Technically true. Just highly misleading and dishonest.

I have personally no beef with full disclosure, and have advocated it as a viable mechanism since the mid 1990's. I also happen to think that responsible disclosure is a good approach, but it definitely needs the threat of FD as a stick, because otherwise vendors would not have any real incentives to work on addressing security bugs. Name-and-shame does work.

Let's get back to AMD flaws. Giving a really short window? Basically just enough to have an initial PR response ready? Have the decency to go full disclosure. Or give a full month. AMD won't be fixing the bugs before news breaks in either case. Just don't claim this is anything but a maliciously crafted exercise with ulterior motives.

What does that even mean? What do you think "ethics" means? This is a nonsensical statement.

The consideration of what people in certain situations should or should not do, IS ethics.

Even if someone would say (for some reason) "but researchers should be able to do their work without consideration", that is making an ethical statement.

I understand why you would have a problem mapping this back to ethics, because if you'd formulate it as such, it would sound kind of bad: Researchers have no ethical responsibilities to the public.

You can't choose to not let decisions be guided by ethics, that's like claiming you choose to find your way without navigating. It makes no sense.

You seem like a living argument for ethical standards being imposed on your industry, by law if needed.

You're arguing that the force of law should prevent you from learning inconvenient things about the software you use.

You are harmed by them discovering a vulnerability and telling the world about it.

And if they discover a vulnerability and tell both you and the rest of the world, the harm may easily outweigh the benefit.

Suppose I go wandering around the city where you live, checking for unlocked house doors. I find that you've left your front door unlocked and gone on holiday. I then wander the streets shouting "Thomas's house is unlocked and no one's at home!". I also phone you up to let you know your house is unlocked.

It was your fault, not mine, that the house was unlocked and no one at home to deter burglars. In principle, anyone else could have come along and burgled your house, if they'd found it before I did. None the less, I think that in this scenario I have done you wrong.

The argument against your position that people are trying to get across to you is not that. It is that publication of vulnerability without giving heads-up and time to prepare solution to the vendor greatly increases the risk that a user will be harmed by attackers exploiting the public knowledge. Often substantial number of users are not going to mitigate or resolve the problem without their vendor giving out the official solution.

It's certainly reasonable to argue which kind of disclosure is the best way to achieve minimal harm, but my opinion is that it's unethical to disclose without considering what method of disclosure will do the least harm, or, worse, just not caring and going for the "biggest splash", as is what it seems these researchers did.

I know everyone in my family is ignorant of this “disclosed” security flaw and is powerless to mitigate the vulnerabilities disclosed on their own. Even if they did know to “turn off their computer” as someone said, are they supposed to wait until someone calls them to tell them a patch is ready?

Disclosing a vulnerability for profit at the expense of everyone else is a shitty thing to do. Would giving AMD a few days to fix it have hurt as many people as giving them one day?

Continued education to help end users get to the point where they can make meaningful and educated decisions is great, and should be pursued, and I do it where I can (though most of the time there's just a shrug and a "whatever"). But, barring that, somebody's gotta make choices on their behalf, and there's a Jerry Garcia quote for this one, you know? With great power comes great responsibility, and we gave ourselves that power. And, outside of a security context, this is why I unflinchingly come down on people who work for shit companies that hurt people, why I'd never hire someone who worked for, say, a toolbar vendor in the 90's/00's and why I have fired clients before when I discovered they were doing shitty things with data gleaned from people who trust them: because we have ethical responsibilities to the people downstream of us who are ill-equipped to make meaningful, educated decisions. I can't compel anyone to do as I do--but I can say that one should, because it's decent.

I can't agree that the power switch is a reasonable mitigation in 2018. In the nineties, sure, but too much of life revolves around this garbage we invented and keep mostly creaking along. (Should it? Probably not. Does it? Yeah.) We are on a ratchet, we can't go back, and kicking the decision down to people who literally-literally lack the tools to make a wise decision while painting a target on them for bad actors who can take advantage of them is profoundly disturbing to me.

This particular vulnerability is a post-compromise privilege escalation flaw, yes. But it strikes me that the conversation must be bigger than that, because the same arguments are used for both. This? Low stakes. Heartbleed? Incalculably high stakes. But the same argument could/would (if it were found by shitheads rather than people with a certain amount of decency to them) be used for the latter instead of the former, and that's what makes me itch.

(And to be clear, irrespective of this conversation, you know I am a big fan.)

I don't see how you get there from here.

But I think that should be done after mitigations are in place to protect end users, or if the vendor is not taking good-faith steps to mitigate the problem.

And I am not saying one should be "restrained from speaking" at all. I am saying that choosing to do so makes one an asshole, and that decent people should strive to not be assholes.

You seem to have several deeply misguided premises.

1. We don't know ARM knowingly shipped these chips although they were vulnerable. Bugs happen.

2. Even if this was the case, an individual can show, and ought to, show decency and empathy towards others.

3. This last comment of yours is a straw man and I doubt you are incapable of seeing this. You parent's argument was much more nuanced and elaborate than your rebuttal.

http://www.cc.com/video-clips/cio5rg/chappelle-s-show-tupac-...

This being a controversial topic straight at the intersection of technology, the way it changed and affected society, the public good and our dependence on technology, I really don't think that "I haven't changed my mind about this in 28 years" supports your argument ...

And honestly I would say that whether I agree or not.

I wasn't working in security but I definitely moved my opinion on the matter. In the (late) 90s I was mostly for full public disclosure arguing the same "we're better off when we have the most information available to us". But today I'm leaning way more towards "responsible disclosure is good" (as you can tell I'm also not 100% black-and-white on the matter like you said you are).

Maybe it's because I was younger then and had more of a reckless mentality and an innocent belief that people will make the right choices given enough information.

Maybe it's because in the past 28 years technology has changed our society to such an extent that impact of security vulnerabilities is rather incomparable to the impact they had back then.

Maybe it's because I definitely don't believe that you can defend this opinion with the very same arguments that were used back then without even addressing the spread of information technology and the drastic way they altered society in the past 28 years.

Maybe it's because I now realise that I myself am not always better off with more information if I can't act on it, and therefore it's not reasonable to assume it as a general rule. Which is very much something I had yet to learn 28 years ago, had to swallow some pride. I wish everybody was a clever as I was back then ...

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)

I don't think this is an appropriate way to argue. Sounds like if he disagrees with you, he is somehow below standard.

> It's just...minimal decency, to care about other people.

Alerting folks to the danger that they face is one way to do so. Responsible Disclosure is caring about the vendor, whereas full disclosure gives other people the chance to take action on their own to remove themselves from harm.

As another note, why not argue for Responsible Development? This is where the outcry should be. Flaws in products come about because they are shipped before they are finished.

That is true, but you missed the other side of the argument. Coordinated disclosure is preferable also to a part of users/customers. Significant part of them have no understanding or incentive enough to mitigate on their own. So the question the discoverer of a bug then faces is 'how much headstart should I give the vendor and the users that depend on the vendor, before I make this public'? This has no universal answer, it may depend on how long the bug is out there and what kind of users may be harmed. But it is easy to see that a little headstart in terms of weeks is more reasonable than headstart=0, especially for bugs that are out there for years.

> why not argue for Responsible Development? This is where the outcry should be. Flaws in products come about because they are shipped before they are finished.

Flaws are not always due to cutting corners. Some bugs in computers are very unintuitive and it could be years before they manifest. More responsible development seems like a good idea, but again, this ignores the other part of the problem - major group of users do not understand the intricacies of development and are not willing to buy more 'responsible' product, if it is 5years behind the newest trend and costs 5x as much.

I answered your question. But you didn't answer my question.

What about the flaws that aren't unintuitive? What about the bog standard integer overflows vendors routinely leave in code because they won't pay what it costs to ensure they don't ship them?

By all means, vendors should be taken to task, and be beaten up even more when a bug was easily avoidable. But a bug's stupidity is completely unrelated to how a user might be harmed by an "irresponsible" disclosure. Giving the vendor their just desserts is secondary to that.

I disagree. This does not account for the fact that malicious actors are likely to exploit these before the vendor fixes them on a schedule that they would prefer to dictate. And all users are not incapable of making alternative judgments about the use of vulnerable technology. Users include my Mom, hackers at small companies, giant corporations who are capable of overnight turning off SMB V1.

The harm to users comes from vulnerable software that the vendors put there in the first place.

So are you talking about AMD being dicks by releasing buggy chips, or the researchers somehow being dicks for finding out?

Related question: if a "food security researcher" discovered a vendor was selling contaminated produce - would it be reasonable for them to give the vendor 90 days notice before telling the public?

While I think it's reasonable and appropriate professional practice for _some people/teams_ to go down the "coordinated disclosure" path (I think the world is a better place for having Tavis Ormandy disclose the way he chooses to), it does without doubt benefit the company who's products are flawed more than the researcher or the public. Anybody who knows they work at a firm that's going to be described dismissively like AMD here did "This company was previously unknown to AMD" is quite likely correct to publish-and-be-damned, because you can bet there's a non-zero chance that AMD's response to non-public disclosure is going to include either stonewalling and stringing the problem out as long as possible, or lawyering up ad threatening to sue the "previously unknown to AMD" company into oblivion.

If you don't want public disclosure of security flaws about your products, either don't make flawed products or don't ship them to the public. Especially if some of the key selling features of said product include bullet points like "AMD Secure OS".

This example is absolutely farcical. It's not even close to the same thing and you know it. A security flaw is not equivalent to poisoned food - it still requires outside action to be exploited.

Everybody releasing chips releases buggy chips. It's the current reality of both hardware and software. Unless they do it maliciously, they're not dicks.

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.

Everyone makes mistakes; it's more about how those mistakes are handled and if a user's control over their computer is respected.

The goal of responsible disclosure windows have nothing to do with saving face for the company. The point is that it gives the company time to come out with a fix so that their customers aren't left with massive holes in the security of their systems.

https://www.iso.org/standard/45170.html

https://hn.algolia.com/?query=author:tptacek%20responsible%2...

Hypothetically speaking, if you are researching vulnerabilities solely for the intent of money (because you can sell to them to 3rd parties or your side hedge fund business can profit from disclosures in the stock market) then shame on you, because you are doing the society a dis-service and gaining on everyone' losses. To me, you are as evil as those hacker who utilize them.

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.

They didn't blow full technical details on this exploit after 24 hours, they went public with a summary... one that's so high-level that many people are even doubting they exist. That's not exactly dumping a zero-day on the internet either.

There's a whole lot of shooting-the-messenger going on with this topic. Making plays against the stock is scummy and possibly illegal, but that doesn't make the exploits here any less real (assuming they are). These are actually quite serious breaks, potentially VMs can jump the sandbox straight into SMM mode and PSP, so it actually is much more severe than just "root password lets you do root things".

https://twitter.com/c7zero/status/973668616183754753

There is a long and storied history of showing the disadvantages of your competitor's products. Edison went on a campaign against Westinghouse's AC electricity, culminating in him electrocuting an elephant to death to demonstrate how dangerous it is.

Right now we need more spotlights on computer security than ever, and as long as it gets bugs patched (hardware, software, or firmware) I don't really care who's doing it or what their short-run motivations are. If AMD won't secure their code appropriately and Intel wants to call them out, fine. If Intel is leaking timings through sidechannels and AMD wants to call them out on it, fine.

And if we want to throw stones here, it was AMD who blew the embargo on Meltdown a week early because they wanted to force a response from Intel at CES... different in degree, not really in kind.

Do you know that the general public are usually the ultimate victims and impacted by those vulnerabilities the most?

Especially Intel/AMD are corporations worth tens of billions monopolies in their fields, and if their CPUs with zero days unpatched and sample code and exploitation techniques out in the wild, what else are you gonna use on your desktop computers?

We've seen similar happened for Microsoft after Shadow Brokers's disclosure.[1] It's gonna be worse for hardware products as it's virtually impossible to retroactively fix silicons chips.

[1]: https://www.wired.com/story/eternalblue-leaked-nsa-spy-tool-...

https://twitter.com/gadievron/status/973655683269873664

It turns out it's exactly the "release a general idea to the public to light a fire under the vendor's ass, only release exact technical details to the people who need to know" that you might expect. They didn't dump a zero-day into public.

"Responsible" to whom? Terms like these indicate what side one takes, such as how one expands the term "DRM": digital rights management means taking the 1%/elite side favored by the publisher, the few in power. 'Digital restrictions management' highlights what's happening from the user's side, the 99%, the side of the many. Similarly with the harm to the users and the desire for freedom in the term "jailbreaking".

So, since we recognize the reporters owe AMD nothing, to whom are they "responsible"? Or what are they responsible for?

This phrase strikes me as useless except to try to foist a responsibility on people that they don't actually have and getting the relatively powerless to serve the interests of power -- users who can't inspect, edit, or share edited CPU microcode are somehow not acting responsibly if they don't give proprietors sufficient notice.

Where is the "responsible disclosure" for Intel when they refuse to let users fully control the signing keys used in the software that sees every network packet before the rest of the computer (for inbound network traffic) and before a packet leaves the computer (for outbound traffic)? The one-sidedness of it all sticks out like a sore thumb.

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

I hope AMD invests the little money needed to fund this sort of PR campaign, er, research initiative, against Intel. The net result would be a greater awareness of the perils of "sponsored" science and of the poor state of PC security.

Dan Guido and Trail of Bits got to read the actual report, and vouched for them as real vulnerabilities. The fact that there are vulnerabilities in signed drivers is a bad thing: it means that AMD shipped cryptographically signed versions of vulnerabilities. Arrigo's twitter thread implied that the use of signed code somehow mitigated the vulnerabilities, but the opposite thing is true.

Suggesting this is "just hypothetical" because "nobody is going to get physical access or code execution in a signed driver" is pretty shortsighted in my opinion...

3. The vulnerabilities are real, but their impact is being overstated because behind the security researchers is a financial firm hoping to make a buck on stock trades.

#3 would seem to me to be a bad development for your niche, if it became a popular business model.

(I have no horse in this race.)

If it was, it’d seem that this research was in support of a financial play similar to how Muddy Waters shorted St. Jude Medical on the basis of insecure medical devices. That would appear to be a legitimate strategy, but if the market didn’t punish Intel for their processor vulnerabilities it seems likely they’d react similarly here and the research would fail to move the stock price in any significant way.

3. The vulnerabilities are real, and something smells real fishy about the way they were released, including what appears to be 4 dudes in a basement.

Except that's not necessarily something to get "outraged" about, just something to keep an eye on while this story develops.

The only one I see shouting "this is an outrage!" appears to .. be made of .. straw?

I’ll add 3. It’s not all about the researchers and AMD, but the people who use AMD chips and deserve a modicum of protection and consideration. Unless there were exploits in the wild, the security of users seems not to have entered into this.

https://news.ycombinator.com/newsguidelines.html