So... and .

Both are triggered by malicious code running on the same hardware as you.

Mitigation means don't put anything important on shared hardware (read: avoid VPSes) and run NoScript or the equivalent in your browser.

Weren't those security best practices already?

Yes, this is a nightmare for VPS providers and worrying for those who placed their trust in virtualization. But the tinfoil-hat brigade has been assuming such bugs existed for ages.

Am I missing anything?

@HerraBRE One OS instance per hardware has been a "security best practice"? No. I don't think it was. And ordinarily it shouldn't be.

@paco The security best practice I speak of is:

"Don't share hardware with untrusted strangers who can run arbitrary code and try to attack your hypervisor or local network."

Of course you should use all the compartmentalization tech that is appropriate for your use case. Even if they can be attacked, it raises the bar.

@HerraBRE Never share hardware with strangers? Seems too blunt.

At face value that would prevent using any cloud infrastructure at all wouldn't it? Seems like it might make SaaS services problematic too.

I don't think I've seen that sort of principle put forward as a best practice. I don't see how you could follow that principle in 2018.

@paco @HerraBRE hi. We keep all sensitive stuff on bare metal. In 2018, just like we did in 2017. And 2016. And before.

So, yeah.

@rysiek @HerraBRE
Why? To what benefit? What attack is on your threat model that is defeated by that design choice?

@rysiek @HerraBRE The date on this advisory is yesterday, and note that at that time 90+% were already done worldwide. Who patches faster than that? aws.amazon.com/security/securi

@paco @HerraBRE that is completely missing the point.

The point is not how fast AWS patched their systems for this. The point is since we were using bare metal in the first place, we were basically not affected in any way.

As in, there was no possible malicious co-tenant on the same hardware that could have extracted anything from our memory space.

Because all memory space is our memory space.

On our bare metal.

@HerraBRE @paco you do realize, I'm sure, that the vulnerability was there way before GPZ discovered it and vendors started working on the fix.

And during that time AWS, Azure, all other Cloud platforms were vulnerable, and their users open to malicious co-tenants.

But again, not on bare metal.

@rysiek @HerraBRE I understand it was there for 20 years. Like the OpenSSL and bash bugs that were old when they were discovered. Do you think it was being actively exploited but somehow nobody knows? It's all been hushed up? Or was it perhaps not actually exploited? I have no idea, myself. But it seems hard to believe that it was being exploited a lot for 6 months, but nobody knew.

@paco @HerraBRE I would not be surprised if it had been actively exploited, yes.

The NSAs and FSBs of this world have budgets way bigger than GPZ. And this is exactly the kind of clandestine, effective vulnerability that nobody expects which the three-letter-agencies love the most.

@rysiek @HerraBRE It's impressive that you've built a data centre that withstands the NSAs and FSBs of this world. If that's your threat model and you've countered it, that's pretty impressive. You must be confident that you've countered that threat better than the cloud providers can, too, which is all the more impressive. I don't know many smal businesses that run data centres capable of resisting the 3-letter-agencies.

@paco @HerraBRE I appreciate your stinging sarcasm there; however I must point out that no-where have I claimed we can resist three-letter-agencies in general.

Nor are we confident we can always protect stuff (on the technical level) better than large providers. Not using their services, however, solves other (non-technical) issues.

@rysiek @HerraBRE
My point is this: security people often reach for the agency threat when they talk about reasons to use bare metal. It's the ONE threat that bare metal seemingly solves. But bare metal ONLY solves that threat if you ALSO do a long list of other expensive security controls. So, given that you probably AREN"T defeating the agencies, what's the point of bare metal? The NSA/FSB threat isn't an interesting security discussion. Nobody (on here) is really designing to defeat them.

@paco @rysiek @HerraBRE you guys suck i had 'defence in depth' on my bingo card. I thought i was going to win 😢

@finux @HerraBRE @paco so let me get this straight:

1. you played bingo
2. you lost
3. you complain about it
4. and it is us who suck?

:P

@rysiek @paco @HerraBRE what else was i suppose to do whilst waiting for the NSA to hack my bingo machine host in my own private AWS

@finux @rysiek @paco Defense in depth dictates avoiding bingo and other gambling.

The house always wins and attacks only ever get better. 😜

· · Web · 0 · 0 · 2

@HerraBRE @finux @paco unless...

Unless we put the bingo on Blockchain! In spaaaaaaace!

@rysiek @paco @HerraBRE problem is the bingochain is now 30% longer than it could have been

@rysiek @paco @HerraBRE all jokes aside you guys all made some valid points. In the end i use cloud services to move traffic around and keep services up, but yes i'm paranoid to make sure some of our more sensitive data stays at 'home'. I'm personally of the opinion that most of the attacks we face are not coming from someone dedicated to pwning us, but just pwning something

@finux @rysiek @paco It's a truism, but understanding your threat model is where it all starts.

Your statement is true for lots and lots of people, but obviously not everybody.

Binary thinking in security is usually wrong. Being a little bit insecure is usually fine, nothing is perfect. Which threats you address first and how depends on your needs.

@HerraBRE @rysiek @paco generally speaking our threats are really no different from anyone else managing consultants on the road, however from time-to-time that changes depending on the client. Basically it's important to remember that 'every individual is an exception to the rule' - stolen from Jung but it works

@HerraBRE @finux @rysiek Right. That's why I get annoyed at the NSA/FSB argument for avoiding cloud. Nobody is really thinking that way. Very few orgs are engineering their data centres or their clouds with defeating an agency as a primary goal. So when I ask "why avoid the cloud?" and the answer comes back "Spooks" it's frustrating. That's not a reasonable conversation. The person saying that is usually not doing enough to avoid spooks on premises. So there's no point bringing it up WRT cloud

@paco @finux Well, in the case of @rysiek , spooks and other powerful adversaries actually are one of their concerns. But he and his org are a minority.

Honestly, the biggest problem with the cloud is one of politics and economics, centralization.

AWS is one of the juiciest targest out there. If I were a TLA I would go after you guys with everything I've got - including lawyers and lawmakers. Not all threats are technical.

@HerraBRE @paco @rysiek be why they got a room in de-cix in frankfurt and cheap at 6k a year too

@rysiek @paco @HerraBRE and of course never mind the exploit delivery agent known as UPS ;)

@HerraBRE @paco @rysiek i mean you could follow that chain all the way down too, if sp00ks are what you're worried about then time to start building your own hardware on your own network isolated from everyone. You have to feel for Cisco when they find pictures of their hardware being intercepted and physical modules being placed into them. In the end, carpentry is always an option to us all :D

@finux @paco @rysiek Burner phones, burner servers.

Bought anonymously with cash from a shop you don't generally frequent...

It's a fun game, this paranoia thing!

I did this by accident, when I impulse-bought a cheap Android set-top box in a supermarket 2.5 hours drive away from my house. Aim to run Mailpile on it at some point. ;)

@paco @HerraBRE @finux sure; it's just as annoying as someone making a blanket statement how they cannot see how anyone can follow the "host on bare metal" principle "in 2018".

Just sayin'.

@paco
kinda late to this one but if you're not American you should look into the work of Caspar Bowden, especially his CCC talk 'the great cloud conspiracy' also the 'lipstick on a pig' talk from this year's CCC about privacy shield.

talking about TLA as adversaries who would attack cloud providers is sort of wrong headed, cloud providers are cooperating parties with them.

not american? no rights.

@HerraBRE @finux @rysiek

@cacahuatl @HerraBRE @finux @rysiek
The point is that TLA adversaries only make sense in your cloud design if they also figure prominently in your data centre design. If you're not designing your business and data centre to defeat the TLAs, why does that come up when we talk about cloud?

@paco
because the providers offer no protection against their native TLAs, instead providing convert access, which is explicitly less protection than doing nothing at all to defend against them.
@HerraBRE @finux @rysiek

@cacahuatl @HerraBRE @finux @rysiek I guess you assume the cloud providers are building backdoors and stuff too? Or maybe they don't really encrypt when they say they do? I mean, at the point you're convinced that they literally lie, how can you trust them at all? And then who can you trust? And how do you trust? I mean "trust but verify", right? But you don't believe the verification.

@paco
correct, you cannot trust them *against their native TLAs*, which is exactly my point. this isn't speculation, it's law and backed up through intelligence leaks :) look at the new laws coming into the UK too under the IP Act. mandates that providers must comply with assisting in "interception of data, and communications and equipment interference". etc, etc, etc.
@HerraBRE @finux @rysiek

@cacahuatl @HerraBRE @finux @rysiek
OK, but if you already exist in that country and already do business there, this effects you no matter what, right? Your upstream isp will have the same laws to follow and issues to deal with. Most AWS customers use AWS in countries where they already do business and have data centres.

@paco

DC location is likely irrelevant, see the recent GMail case: stored in goog EU DC, requested by US, goog had to comply and hand over data from EU DC to US DOJ for EU user.

similar Microsoft case with Irish DC and email record and US DOJ.

the list is endless. check out Bowden. :)

@HerraBRE @finux @rysiek

@cacahuatl @HerraBRE @finux @rysiek But now you're mixing issues. You're talking about an individual person's concerns about privacy threats from TLAs and you're using that to discuss what an enterprise should choose for its data centre. AWS isn't what individuals use for privacy. It's what businesses use for their core IT. I don't see how the two things are related. I will go watch the talks.

@cacahuatl @HerraBRE @finux @rysiek
Just to be clear, the fact that the US can subpeona data from an EU data centre about EU citizens is why a US company doing business on US soil should not use US regions of a public cloud provider? Or why a UK company doing business in the UK shouldn't use a UK region of a public cloud provider? I'm not sure enterprise IT functions do the risk analysis this way. I'm not sure they should. There are lots of other factors to consider.

@paco
the fact that US law considers it US data to be taken from a US company shows that if it's a US company, no matter the DC location, US TLA will get covert access by the companies co-operation. this is likely true of all countries and their native TLAs. if you put data into a US companies cloud, US IC gets it and we should act accordingly.
@HerraBRE @finux @rysiek

Show newer
Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!