Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

dig.security

Post reply on HN
Print view View original

41–50 of 54 posts

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#41

Post by GSGBen »

hn_throwaway_99 wrote: post #27
lima wrote: post #24

Earlier quoted context omitted.

Yes. They don't want you to be able to poke around but the real security boundary is the VM, not the database server.

Back when there was a critical Azure bug that enabled an Azure user to gain access to top-level keys (i.e. the keys to the entire kingdom), a Google engineer commented on an HN thread that Google specifically didn't consider container boundaries secure, so everything is always tied to a VM specific to a customer. The issue with Azure is that a container escape allowed a user to take over the entire Azure subsystem.

Not sure if this is still true RE: Azure. AFAIK they use Hyper-V (hypervisor) containers which offer kernel isolation like other lightweight-VM-container runtimes.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#42

Post by kccqzy »

speedgoose wrote: post #30

Isn’t the blur effect too light on the screenshots? I may be possible to recompute the /etc/shadow file.

And what would that accomplish? Knowing the contents of /etc/shadow of a random (virtual) machine that belonged to someone else that you could not access, one that most likely already ceased to exist.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#43

Post by HyperSane »

azurezyq wrote: post #32
londons_explore wrote: post #13

Earlier quoted context omitted.

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!

I was part of GCP Cloud Dataflow team a few years ago. The status page is actually the standard for all google internal services (/statusz). I still miss them much. 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 ch…

Containers should never be treated as a security boundary.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#44

Post by ryanjshaw »

VWWHFSfQ wrote: post #28
jorams wrote: post #20

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

Also no details about what severity the vulnerability was assessed as. For all we know they got a $10 Play Store voucher because the security boundary is the VM, and SQL customers are already paying for the VM and the rest is convenience so they are considered to be hacking themselves here. Reading this was a waste of time.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#45

Post by speedgoose »

kccqzy wrote: post #42
speedgoose wrote: post #30

Isn’t the blur effect too light on the screenshots? I may be possible to recompute the /etc/shadow file.

And what would that accomplish? Knowing the contents of /etc/shadow of a random (virtual) machine that belonged to someone else that you could not access, one that most likely already ceased to exist.

It’s still a bad practice to blur information that supposed to be hidden.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#46

Post by havetocharge »

ryanjshaw wrote: post #44
VWWHFSfQ wrote: post #28

Earlier quoted context omitted.

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

Also no details about what severity the vulnerability was assessed as. For all we know they got a $10 Play Store voucher because the security boundary is the VM, and SQL customers are already paying for the VM and the rest is convenience so they are considered to be hacking themselves here. Reading this was a waste of time.

There's a big fat NDA attached to the reward.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#47

Post by kramerger »

cflewis wrote: post #40
lima wrote: post #19

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 was part of the Cloud SQL team when putting databases in VMs was designed (previously the MySQL process was run in a sandbox). 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 implementa…

Not a huge fan of Google, but I have always admired how they prioritise security.

This would never fly at Amazon because it would cost them a few cents to have anorher VM. Microsoft would probably not even notice the issue.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#48

Post by abwizz »

havetocharge wrote: post #46
ryanjshaw wrote: post #44

Earlier quoted context omitted.

Also no details about what severity the vulnerability was assessed as. For all we know they got a $10 Play Store voucher because the security boundary is the VM, and SQL customers are already paying for the VM and the rest is convenience so they are considered to be hacking themselves here. Reading this was a waste of time.

There's a big fat NDA attached to the reward.

maybe security researchers would be well advised to establish a kind of name and shame culture for this NDA with benefits thing that mainly serves to protect corporate interests.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#49

Post by scarface74 »

kramerger wrote: post #47
cflewis wrote: post #40

Earlier quoted context omitted.

I was part of the Cloud SQL team when putting databases in VMs was designed (previously the MySQL process was run in a sandbox). 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 implementa…

Not a huge fan of Google, but I have always admired how they prioritise security. This would never fly at Amazon because it would cost them a few cents to have anorher VM. Microsoft would probably not even notice the issue.

All AWS RDS databases run on a dedicated VM.

Re: GCP CloudSQL Vulnerability Leads to Internal Container Access and Data Exposure

#50

Post by flaminHotSpeedo »

hn_throwaway_99 wrote: post #27
lima wrote: post #24

Earlier quoted context omitted.

Yes. They don't want you to be able to poke around but the real security boundary is the VM, not the database server.

Back when there was a critical Azure bug that enabled an Azure user to gain access to top-level keys (i.e. the keys to the entire kingdom), a Google engineer commented on an HN thread that Google specifically didn't consider container boundaries secure, so everything is always tied to a VM specific to a customer. The issue with Azure is that a container escape allowed a user to take over the entire Azure subsystem.

It's not a mistake unique to Azure, Alibaba had a vulnerability make the news rounds recently where container escapes led to cross tenant access.

There's two types of cloud providers, the ones who take security seriously and the ones who learn security the hard, public way.

I'm a bit surprised that Azure would get lumped in with the other cut-rate providers but that's becoming more and more obvious with the vulnerabilities of the past few years.

Post reply on HN