3 ms·

I agree it is impressive. But if you are running your own hardware, you probably aren't sharing CPU time with strangers as GCP is.

tzar 9y ago
That's a fair point, but somehow the nervous feeling isn't limited to sharing CPU time with strangers! The amount of platform complexity abstracted by the GCP services is staggering. This is the job of taking a (hopefully) understandable piece of computer code that represents some real-world logic and installing it into reality, in a sense. It's clear that it's a very messy world out there for a program.
boulos 9y ago
Disclosure: I work on Google Cloud. Even if you aren't sharing with "strangers", applications may be vulnerable to these attacks. For example, the JavaScript attack clearly applies to people's individual computers. If you take untrusted code and execute it, you might be vulnerable to these intra-"instance" information leaks. It all comes down to your threat model though. Some people are rightly worried about insider risk. If a malicious employee can go run a binary on your shared computing infrastructure to get root credentials out of a machine, that's actually a real problem. Then again, there are lots of ways for a rogue employee to do bad things, so this is "just" another one. But don't take this as "only applicable to shared cloud environments", because it's not.
- qaq 9y ago
  Sure but when you are worried about insider risk (and even if you are not) you most likely have strong access controls, extensive logging, endpoint security solution that can mitigate or at least alert on this activity.
  - toomuchtodo 9y ago
    To manage insider risk, we do everything you mention (as well as much more I can’t mention). We treat insider risk the same as external threats: ever present and requiring constant vigilance. The VM is not considered a security boundary any longer; tenancy controls are now in place, to prevent attacks similar to Meltdown and Spectre that are yet undiscovered.
- cm2187 9y ago
  I am not too worried about javascript as it runs in a VM where the browser has full control on how code gets executed, and I trust browser vendors will come up with a mitigant. Otherwise on a personal computer, if malware gets to execute in user mode, being able to access some machine private key is the least of our worries. The sensitive information is the documents stored on the machine, whether it is for them to be leaked or encrypted, if the code can access them in read/write, the party is already over.
- merb 9y ago
  well there are still people out there who do not have these problems, i.e. people who have just a "few" employees to manage infra. people who have VMs just to actually limit compute nodes. Actually we have our Test Infrastructure seperated from the rest, so basically only this runs untrusted code.

tzar 9y ago

That's a fair point, but somehow the nervous feeling isn't limited to sharing CPU time with strangers! The amount of platform complexity abstracted by the GCP services is staggering. This is the job of taking a (hopefully) understandable piece of computer code that represents some real-world logic and installing it into reality, in a sense. It's clear that it's a very messy world out there for a program.

boulos 9y ago

Disclosure: I work on Google Cloud. Even if you aren't sharing with "strangers", applications may be vulnerable to these attacks. For example, the JavaScript attack clearly applies to people's individual computers. If you take untrusted code and execute it, you might be vulnerable to these intra-"instance" information leaks. It all comes down to your threat model though. Some people are rightly worried about insider risk. If a malicious employee can go run a binary on your shared computing infrastructure to get root credentials out of a machine, that's actually a real problem. Then again, there are lots of ways for a rogue employee to do bad things, so this is "just" another one. But don't take this as "only applicable to shared cloud environments", because it's not.

qaq 9y ago
Sure but when you are worried about insider risk (and even if you are not) you most likely have strong access controls, extensive logging, endpoint security solution that can mitigate or at least alert on this activity.
- toomuchtodo 9y ago
  To manage insider risk, we do everything you mention (as well as much more I can’t mention). We treat insider risk the same as external threats: ever present and requiring constant vigilance. The VM is not considered a security boundary any longer; tenancy controls are now in place, to prevent attacks similar to Meltdown and Spectre that are yet undiscovered.
cm2187 9y ago
I am not too worried about javascript as it runs in a VM where the browser has full control on how code gets executed, and I trust browser vendors will come up with a mitigant. Otherwise on a personal computer, if malware gets to execute in user mode, being able to access some machine private key is the least of our worries. The sensitive information is the documents stored on the machine, whether it is for them to be leaked or encrypted, if the code can access them in read/write, the party is already over.
merb 9y ago
well there are still people out there who do not have these problems, i.e. people who have just a "few" employees to manage infra. people who have VMs just to actually limit compute nodes. Actually we have our Test Infrastructure seperated from the rest, so basically only this runs untrusted code.