31–40 of 54 posts
So this blog post is missing any information about what the actual vulnerabilities were. What was the "gap"? What was the misconfiguration? Also missing is whether access to the host VM exposes meaningful secrets. Does this actually risk customers' sensitive data?
Yeah this was terrible. First, we did a privilege escalation. How? They don't say. Next, we did another privilege escalation. And how?? They don't say. what's the point of this
Earlier quoted context omitted.
The other way to see it, is that it took them 8 days to notice a full compromise of the hosting OS and an open access to Google’s internal docker image repository URL.
I'm going to guess that this VM was considered the 'customers' VM as far as security goes... Ie. you couldn't access any other customers data. Likewise, GCP Dataflow quite trivially allows you to escape onto the worker machines and take the (huge) binaries that implement it. They have some really nice detailed status pages!
In dataflow's case, container is not treated as the boundary. And there are several important things to note:
- Dataflow's VMs are in customer projects, so there's no risk of cross-tenant access.
- When launching dataflow jobs, the launcher identity is checked to have iam.serviceAccountUser IAM role, which means that the identity should be able to launch a VM with the same service account just fine. So dataflow is not escalating the permission beyond GCE VMs.
- Just as VM launched by someone, if anyone else can log onto those VMs are controlled separately.
- Container is used in dataflow only for convenient image delivery, not for a security barrier. VM is.
Presenting it as a Cloud SQL problem is disingenuous.
Earlier quoted context omitted.
It's responsibly disclosed after the hole is patched.
The term of art is "coordinated" disclosure. All sorts of disclosures, with or without vendor consent, can be "responsible", so we try not to use that term, which was coined as a device to give vendors power over researchers.
The vulnerability sounds like it's inherent to SQL Server, and that cloud providers haven't been successful in blocking the underlying problem due to its proprietary nature. Presenting it as a Cloud SQL problem is disingenuous.
> we identified a gap in GCP’s security layer that was created for SQL Server. This vulnerability enabled us to escalate our initial privilege and add our user to the DbRootRole role, a GCP admin role.
So Google took proprietary software not designed for this use-case and built their own security layer on top of it and ended up with bugs.
Of course that's an issue with the service. Presenting it as anything else than an issue in Cloud SQL seems disingenuous.
I'm pretty impressed with the GCP response, both the fact that they identified the behavior and took the first step in reaching out.
The other way to see it, is that it took them 8 days to notice a full compromise of the hosting OS and an open access to Google’s internal docker image repository URL.
Earlier quoted context omitted.
The other way to see it, is that it took them 8 days to notice a full compromise of the hosting OS and an open access to Google’s internal docker image repository URL.
It took 8 days to proactively reach out. It may very well have been identified earlier and then taken some time to be passed off to Google's vulnerability reward program and get any approvals necessary
Earlier quoted context omitted.
The other way to see it, is that it took them 8 days to notice a full compromise of the hosting OS and an open access to Google’s internal docker image repository URL.
I'm going to guess that this VM was considered the 'customers' VM as far as security goes... Ie. you couldn't access any other customers data. Likewise, GCP Dataflow quite trivially allows you to escape onto the worker machines and take the (huge) binaries that implement it. They have some really nice detailed status pages!
The vms are somewhat hidden in the UI iirc but otherwise you can enumerate them via API and ssh to them and debug/profile (which I was doing to get cross-language profiling on data flow pipelines with py-spy and jvm perf output).
It's just a worker vm in your project.
Last time I checked, their hosted databases run in dedicated VMs, which is where the real security boundary is. Getting access to the host OS won't give you much other than some internal binaries and config.
I am sure Cloud SQL is far more advanced since then (9 years ago), but security in depth was something we thought about a lot. Running in a VM for each database rather than a multi-tenant system was for security more than anything else. We could have multi-tenanted just as easily implementation-wise.