search

liamg / traitor

:arrow_up: :skull_and_crossbones: :fire: Automatic Linux privesc via exploitation of low-hanging fruit e.g. gtfobins, pwnkit, dirty pipe, +w docker.sock
MIT License
6.68k stars 578 forks source link

Docker exploit mitigation #71

Closed taoeffect closed 2 years ago

taoeffect commented 2 years ago

(Note: I would ask this in a discussion but those haven't been setup yet- so another vote for enabling those: #70)

Sorry if this is the wrong place to ask this question - but I searched these issues, and I searched the web, and I can't find anything good on it.

Having docker.sock writable by the docker group is extremely handy/useful. However, I don't want to allow that as it results in this root exploit.

Is there any way to have docker.sock writable but without enabling this exploit? Is it a fundamental problem with Docker's design? Seems like a big deal...

prologic commented 2 years ago

Are you giving users access to the docker group and thereby decreasing your security?

taoeffect commented 2 years ago

Yes, I have a user that is part of the docker group, so that it can run docker commands without having to run sudo. I guess you're not supposed to do that? Sudo is required to use docker command..?

prologic commented 2 years ago

It actually doesn't really matter whether you run sudo docker ... or docker ... (if you're part of the docker group and the /var/run/docker.sock UNIX socket is group read/write-able)

What matters is that you should not be using sudo or "elevated" privileges unnecessary. It is recommended therefore to not run docker client cli commands under root. You are doing the right thing there.

The fact you can do rather nasty things with Docker itself is a side-effect of it's design. You should look into Docker Security and apply what makes sense to you in your environment.

taoeffect commented 2 years ago

@prologic I don't understand though - Docker is an extremely common tool on most Linux servers and systems.

By DEFAULT it seems to result in a root privs escalation exploit.

That is INSANE. How is that at all acceptable? How can it be industry standard to ship a root privs exploit and not have that be called criminal negligence?

You should look into Docker Security and apply what makes sense to you in your environment.

I quickly looked into that and saw nothing as far as mitigating this exploit.

How do I prevent it?

And why is it even there in the first place?

(Who do I sue?!)

prologic commented 2 years ago

@taoeffect let's not get all melodramatic here. Docker is a tool, not a root exploit. It is no worse than adding users to the sudo group.

In your specific case:

Good luck. I'm closing this issue.

taoeffect commented 2 years ago

Docker is a tool, not a root exploit. It is no worse than adding users to the sudo group.

When someone adds a user to the sudo group, that doesn't result in a root privs exploit. So I don't see how that's comparable.

Reconfigure your Docker daemon to listen on TCP (port 2376) with TLS certificates.

This will somehow fix the exploit? Can consider doing that if it's true.

taoeffect commented 2 years ago

There is a note at the bottom of this section that says:

Warning: As shown in the example above, you don’t need to run the docker client with sudo or the docker group when you use certificate authentication. That means anyone with the keys can give any instructions to your Docker daemon, giving them root access to the machine hosting the daemon. Guard these keys as you would a root password!

So it sounds like it doesn't do anything to prevent the exploit. Any user that can use the docker command, whether it's via the UNIX socket, or via TLS, can gain root privileges, and there's nothing stopping them. It's by design.

Whereas with a user in the sudo group - a password must be entered for them to gain root.

It seems like Docker violates the basic UNIX security model, and people are just OK with that.

prologic commented 2 years ago

@taoeffect I don't know what to tell you, this however isn't the place for this discussion.

There are tonnes of material on this in the wild. You might be interested in "Rootless Docker" too. Or even some alternative implementations like podman? The reality is, no-one that I know of (in their right mind) would ever give any "untrusted" users access to Docker on any system. I personally use Docker as more of a "Packaging" tool than anything -- which coincidentally is really what it's good for. -- The fact that I run and operate Docker Swarm clusters in production is besides the point -- I never permit anyone access to these clusters on any level. If you think of Docker or Docker Swarm as a "container orchestrator", you really don't have a "root exploit".

You might also want to look into other "container orchestrators" out there like:

taoeffect commented 2 years ago

Thanks @prologic. Yeah those alternatives might be the only real option if I want to avoid this issue.

The reality is, no-one that I know of (in their right mind) would ever give any "untrusted" users access to Docker on any system.

Nobody intends to voluntarily do such a thing. But exploitable bugs exist that could give a hacker access to your docker equipped user. Once they do that there's nothing preventing them from installing a root-kit on your server. If Docker respected the UNIX security model, basic UNIX permissions could at least protect you (as would be expected).