6 ms·
While it certainly seems like a fairly serious vulnerability I think it's worth highlighting that this attack requires that either you already have access to a
by remus 5y ago
While it certainly seems like a fairly serious vulnerability I think it's worth highlighting that this attack requires that either you already have access to a machine on the same subnet as the target machine or that the firewall in front of the target machine is very lax. That's a pretty high bar for getting the attack to work in the wild.
- tryauuum 5y agoI wonder if they have actually tested the last scenario: > Targeting a VM over the internet. This requires the firewall in front of the victim VM to be fully open. I mean, even if the firewall is non-existing, can you really carry a dhcp payload over the public internet? EDIT: still haven't read the whole thing, but looks like they did test it
- asah 5y ago-1: consider if you have complex vendor software on a GCE VM inside a larger GCP project... now a vulnerability in that vendor software means the whole GCP project is exposed. Vendor fixes are notoriously slow, so in practice you have to isolate vendor software to separate GCP projects. Real example: I have a client with precisely this situation, and elsewhere in the GCP project is PII consumer data requiring public disclosure if exposed.
- exitheone 5y agoI think the real learning here is not to colocate different things in a single GCP project. AFAIK projects don't cost anything so why not create one per service?
- asah 5y agoThe way you're wording this suggests that this was a sensible design prior to this vulnerability, but in fact all sorts of tools, config, etc work within a project but not across projects, including IAM. Yes obviously anything can be duplicated but it's a big pain. Probably easier to create separate subnets for VMs that don't trust each other ?
- briffle 5y agoIAM works across projects easily. The "Organization" concept it Google Cloud is used to collect projects, and manage permissions of groups (or subfolders) of projects very easily.
- rantwasp 5y agothe real learning for me is to not use gcp. sounds harsh, but you don’t get second chances when it comes to trust in this context.
- remus 5y agoI completely agree and didn't mean to suggest it wasn't a serious vulnerability: as I understand it this attack means that if any VM in the subnet is compromised that can be leveraged in to an attack on any VM in the subnet so your attack surface has suddenly gotten a lot bigger and your isolation between VMs substantially poorer.
- mywittyname 5y agoLuckily, GCE limits Cloud API access available to an instance to nothing by default. Meaning that access to BigQuery, Storage, SQL, User manage, etc is not allowed on that VM, even with root access to the VM, unless configured by the administrator. This at least mitigates the the impact of this exploit to a degree. If a web server has access only to Cloud SQL, an attacker cannot use access to that VM to go digging around in Cloud Storage buckets unless GCS access is granted explicitly to the VM. From there, IAM security applies. So even if the VM has Cloud API access to, say Big Query, the limitations of that Service Account then applies to any data that is accessed.
- cmeacham98 5y agoNote that "have access to a machine on the same subnet" really just means "can send traffic to the VM local network". In other words, partial compromises (ex: docker container, VM, chroot) that have access to this network are enough, as well as attacks that let you send traffic (ex: TURN server abuse)