Live data from Hacker News

Into the Borg – SSRF inside Google production network

opnsec.com

1–10 of 79 posts

Re: Into the Borg – SSRF inside Google production network

#3
This is a great find. SSRF is a really unappreciated vulnerability; it is usually game-over. That it came from a Caja audit adds some tasty irony.

A friendly word of advice: when you find flaws like this (you, the reader, not you, the guy who wrote this post), think carefully before disclosing internal network details you discover like this writer did. The internal details of a target network don't become public domain simply because you found a vulnerability. There are firms that get extremely itchy about this kind of stuff getting published, and I can't blame them.

Re: Into the Borg – SSRF inside Google production network

#6
Not quite relevant to the article: Since it seems to be tricky to properly sanitize URLs for SSRF, I had an idea for safely calling user-defined URLs: Set up an unprivileged non-VPC Lambda function that calls a URL and call all user-defined URLs through the Lambda function. I think it should be bulletproof, anything I'm overlooking?

Re: Into the Borg – SSRF inside Google production network

#7
post #6

Not quite relevant to the article: Since it seems to be tricky to properly sanitize URLs for SSRF, I had an idea for safely calling user-defined URLs: Set up an unprivileged non-VPC Lambda function that calls a URL and call all user-defined URLs through the Lambda function. I think it should be bulletproof, anything I'm overlooking?

GCP does it by requiring a header on requests to metadata systems.

Require a header on your internal services and make sure you never send that header with user-requested URLs and you can guarantee safety there.

Re: Into the Borg – SSRF inside Google production network

#8

> I should mention that Borg, like Kubernetes, relies on containers like Docker Hmm, containers _like_ Docker, or Docker? I thought Google used lmctfy since long before Docker?

cgroups were written at Google, and have been used internally for a very long time; they provide "container"-like limits on resource usage for a group of processes.

I assume that Google isn't using Docker internally for production services, but don't know for sure (and I assume anyone who does know for sure can't tell you).

Re: Into the Borg – SSRF inside Google production network

#9
post #8

> I should mention that Borg, like Kubernetes, relies on containers like Docker Hmm, containers _like_ Docker, or Docker? I thought Google used lmctfy since long before Docker?

cgroups were written at Google, and have been used internally for a very long time; they provide "container"-like limits on resource usage for a group of processes. I assume that Google isn't using Docker internally for production services, but don't know for sure (and I assume anyone who does know for sure can't tell you).

Yeah, so to clarify, I know from the Borg paper that Google basically implemented the first cgroups and the first cgroups-based containers. I'm pretty sure that lmctfy was the open-sourcing of this work, but it's also been deprecated and last I heard, that code was moving to libcontainer/runc.

If (as the article implies) Google uses Docker internally, that would be a surprising and interesting bit of news.

Re: Into the Borg – SSRF inside Google production network

#10
post #8

> I should mention that Borg, like Kubernetes, relies on containers like Docker Hmm, containers _like_ Docker, or Docker? I thought Google used lmctfy since long before Docker?

cgroups were written at Google, and have been used internally for a very long time; they provide "container"-like limits on resource usage for a group of processes. I assume that Google isn't using Docker internally for production services, but don't know for sure (and I assume anyone who does know for sure can't tell you).

They mentioned that Kubernetes runs some workloads and they are probably using Docker for that, like GKE does (17.03, I think). No way they would use it for Borg.
Post reply on HN