Hacker News Reader

Comment by saas_co_de | Hacker News Reader

Embargos do not make you secure. If the bug exists the only safe assumption is that it is already being exploited.

The faster the information gets out the better.

People are generally willing to make the slightly less safe assumptions that targeted and mass attacks are different threat models, and that coordinated disclosure might not help against the former but does help against the latter.

People are willing to make these assumption because they correspond closer to reality.

No, but they prevent everybody with ill-intent from exploiting the issue en-masse

No they don't. They prevent everybody with ill intent who doesn't already know about it from finding out about it from the guys without ill intent. That's all.

would you say it prevents the small fry from having a big impact?

edit: I think the mirai botnet(s) had some sort of power struggle? avoiding propagating knowledge about it prevents it from being easily exploited by more actors.

The reality is that there's a group you're excluding from consideration and I don't think it's unreasonable to conclude that embargoes keeps every random "hacker" from taking advantage of it in a packaged form. Being vulnerable to the minority population that can and would take advantage of it vs. anyone that would is a valid consideration and shouldn't be dismissed so casually.

Once there is disclosure then 100% of users can make the choice to take appropriate mitigation steps.

Prior to disclosure there will always be the possibility that some users are being exploited without their knowledge.

Therefore disclosure always improves the situation by giving those who could have been exploited without their knowledge the choice to take mitigation steps.

All of the "responsible disclosure" nonsense is just PR by companies who want to avoid the most obvious mitigation, which is for customers to stop using their products.

> Once there is disclosure then 100% of users can make the choice to take appropriate mitigation steps.

And what are those mitigation steps?

Depends on the exploit, but all exploits can be mitigated by stopping your use of the exploited product. That is what companies don't want to happen so they would prefer to sacrifice their users' security and wait until they have a fix before the exploit is disclosed.

In this specific scenario what's the mitigation for cloud customers? Or even cloud providers? A customer can't migrate all of their infrastructure before a packaged exploit can be distributed. A provider can't dedicate hardware for every single customer. Let's be realistic here.

Get off the cloud. Which is exactly why the companies involved would want to keep it secret.

Not everyone is all in on cloud infrastructure. What about people who are right now deciding whether or not to move critical data to the cloud? Should their security be compromised by hiding the truth about a known exploit in order to "protect" people less concerned about security who already put their data at risk?

How is Netflix going to move off the cloud overnight?

If this vulnerability applies regardless of where it is, what is the mitigation then? Move your machine to where? Your suggestion is not practical and you know it. The right mitigation is one that actually will fix the vulnerability. No one shut down machines and migrated everything to another distro because Debian had a bug in generating private key a decade ago even if the bug was zero-day.

One might migrate some super important instances to bear metal or cloud hardware under full control. If this is an embargo against a bug that could make VMs on the same hardware attackable this should be public.

This is the classic case of the frog being boiled. Or the pig getting lazy...

At every step along the way, there's been a choice of "Well, we could own the hardware and incur overhead costs, or we could trust someone else and pay our share of lower overhead. It'll mean giving up some control, but it'll save us a few bucks."

Or maybe it goes like "Well, we could develop with practices that result in more robust code, but we'd be slower to market."

There's definitely a sidetrack of "If we crank up the clock too much, all sorts of things get wibbly and we can no longer guarantee that the outputs match the inputs, but we don't actually have ways of doing it correctly at these speeds. The press will slam us if we don't keep pace with Moore's law, how could we launch a product with only marginal speed gains?"

And pretty often I think it sounds like "The ops staff says they're overworked and we need to add people or we risk an incident, but Salesman Bob says we can actually fire most of them if we put our stuff in BobCloud."

At every step along the way, someone made a conscious choice to do the insecure thing. The folks with their eye on security were dismissed as naysayers, and profit was paramount. And because these practices became so common, they became enshrined in market norms and expected overhead costs.

> A provider can't dedicate hardware for every single customer.

A provider absolutely could dedicate hardware for every single customer, that's literally how every provider operated before virtualization. It just wasn't as profitable as virtualization.

The story of the Three Little Pigs was supposed to teach about the importance of robust infrastructure. Nobody should be surprised when the wolf shows up. And every pig had the choice to build with sticks or bricks, it would just take more work or cost more.

And I see your message as saying "Are you serious? Build with something other than straw?! But we already own so much straw! All the pigs have straw houses, won't someone think of the pigs?"

Meanwhile the bankrupt brick vendor's assets have been auctioned off, and the wolves are salivating.

The three little pigs taught me "Don't bother putting in the hard work; because when the shit hits the fan, someone else will happily bail you out".

If this guy can figure this out, anybody with the means and motivation to write such an exploit is already working on t.

Exactly. This is just some random nerd. There are people all over the world whose full time job it is to track open source projects to develop exploits.

and when script kiddies get wind that there is something potentially disastrous in the open, it can be exploited 10 times harder, that's all I'm saying.

I understand (and agree) that the system admins/owners should also be able to mitigate through knowledge, but it's a dilemma that I think is better resolved by the other solution

(in this case it's apparently a complex issue, but history has shown that there are surprisingly easy to exploit bugs/issues (see heartbleed, shellshock (which was apparently very quickly exploited.))

No "script kiddies" can write exploit code for something on this level.

This guy is not releasing an exploit implementation, he is just pointing to the existence of a potential exploit that has a patch in development. He can't even figure out exactly what it is.

The only people who would be able to code this exploit would be the ones who already figured it out before this guy.

All of the serious hackers with resources have a paid mole involved in the embargo discussion mailing list. The most dangerous people already know.

Embargo is simply a way to make sure the huge, rich cloud providers don't have their reputation tarnished at the expense of everyone else. "Stay with bigco, we fix things before everyone finds about it"

Reply on news.ycombinator.com