Comment by eeZah7Ux
5 years ago
> just a kernel + Go binary running as init
This is hardly reducing the attack surface compared to a good distro with the usual userspace.
It's been decades since attackers relied on a shell, or unix tools in general, or on being to write to disk and so on: it's risky and ineffective.
Many attack tools run arbitrary code inside the same process that has been breached and extract data from its memory.
They don't try to snoop around or write to disk and so on. Rather, move to another host.
The only good mitigation is to split your own application in multiple processes based on the type of risk and sandbox each of them accordingly.
> This is hardly reducing the attack surface compared to a good distro with the usual userspace.
Run `tcpdump -n 'tcp and port 80'` on your frontend host and you'll still see PHP exploit attempts from 15 years ago. Not every ghost who knocks is an APT. A singleton Go binary running on a Linux kernel with no local storage is objectively a smaller attack surface than a service running in a container with /bin/sh, running on a vhost with a full OS, running on a physical host with thousands of sleeping VMs—the state of many, many websites and APIs today.
> is objectively a smaller attack surface
No, you have to understand what is really part of the attack surface and what the attacker wants.
For example, on a properly built system with a single application running with its own user the attacker might have no practical benefit at all in doing a privilege escalation to root.
> running on a physical host with thousands of sleeping VMs
This is a strawman. A shared hypervisor opens another attack surface and was not part of the discussion.
Look, my friend, we will have to disagree on this. What exploits will attack this setup from the front? A Linux networking or other syscall RCE, a Go compiler intrinsic RCE, a vulnerability in the app code, or a vulnerability in a third party library. All of which exist in the common OS-hosted scenario, in addition to everything else, plus you have both your container and your OS to worry about (e.g. openssl).
EDIT: Anyway, I'd like to thank Mr. Bogdanov and his client for sharing this story—it's just fascinating.
3 replies →