Docker SecuritySpecific reasons why Docker sucks

Disclaimer: I’m using Docker wrongLet this presentation be a discussion of Docker, it’s threat model, and security concerns and not a recommendation of how you should use docker. All examples of using docker in this presentation are exactly opposite of how you should be using docker. If you’re interested in microservices on your internal network, testing out applications, or developing applications for a San Francisco startup, docker may be a perfect solution. If you just want to run a website, containers do have a substantial benefit.

1970-80’s: Mainframes

The Applicatio

n

1980-90’s: Thick Apps

App Ap

pApp

App

App

App

App

1990-00’s: Segregation

App Ap

p

App

App

App

App

App

2000’s: Virtualization (Same)

App

App

App

App

2000-2010’s: The Cloud

Your app

Your app

Someone else’

sapp

Today: ContainersYour appYour appYour appYour appYour appYour appYour appYour app

NotYour app

NotYour app

NotYour app

NotYour app

Your appYour appYour appYour app

Your appYour appYour app

Your appYour appYour app

Your appYour appYour app

Containers today vs yesterdayToday• Disposable• “I don’t care if I’m

hacked, I’ll just rebuild” – Jason

• Low profile• Unikernels take up

MB’s not GB’s• Scalable

Yesterday• Very important• DON’T TOUCH

THAT SERVER OMG DOWNTIME

• High resources:• “Fuck it, just install

QT”• Not scalable

Example

Bsidesroc.comwordpress

Antitree.comwordpress

Joethecoolestguyontheinternet.com

Jwilder/nginx-proxyAntitree.com

MySQL

Bsidesroc.comMySQL

Static HTML

Jrcs/lets-encrypt-nginx-proxy-companion443/TCP

443/TCP

443/TCP

443/TCPbriancranston 9030/TCP

Containers vs VMs• Containers ~= chroot (on meth)• Think virtual environment• They have much lower overhead than VMs

(micro/unikernels)• Fast but they are not hardware backed

virtualization• Namespaced process separation not true

isolation• They really have nothing to do with VMs• Why are we even comparing them to VMs? This

slide is stupid

Container Security• Containers have been around for decades

but not for security• Docker made containers popular and

sexy• Oh wait, security? Fuck it, move to

production• But why are they insecure?

Background: Namespaces• Creates a logical separation of resources• Namespaces are the core of containers• Types of namespaces:• Network: isolated network stack• Mount: namespaced mount points• UID/PID: namespace isolation of process and

user ID’s (root inside does not mean root outside)• Cgroups: controls for shared resources

Background: Capabilities• A capability is a *nix action a user can perform• Goal is to restrict “capabilities”• Privileged process = all the capabilities!• Unprivileged process = check individual user

capabilities• Example Capabilities:

• CAP_CHOWN• CAP_SETUID• CAP_NET_RAW• CAP_SYS_RAWIO

Background: AppArmor• Linux Security Module • Second line of defense for containers• Restrict various actions based on a policy• Example: Mounting

• Block access to /dev/pts so a container can’t read a host’s terminaldeny mount fstype=devpts

• Example: Utility access• Block access to /proc/sys/kernel/modprobe so that

attackers can’t replace it with arbitrary codedeny /proc/sys/kerne[^l]*{,/**} wklx,

Background: Seccomp• Restricts system calls based on a policy• Block things like• Kernel manipulation (init_module,

finit_module, delete_module)• Executing mount options• Setting the system time• Reboot

• Blacklist based• Same technology that Subgraph bases

their container protections on

The Root ThreatA privileged container – one that is running with root privs -- is your biggest threat to the host computer• Think of all the attack vectors your

container could have access to• Mounted volumes• Logging resources, scheduled tasks• Kernel drivers• Shared devices

1. RW Volume Abuse• Containers allow you to mount a host volume

inside of a containerdocker run -it -v /usr/local/bin:/bin apache

• When root is always root – if the container is exploited, they will have root access to the above host system. • Defense:• Don’t be an idiot• Make sure that your images are all unprivileged

• This is why it’s so important to run unprivileged containers

2. Docker socket control• Some containers will mount the Docker

socket so it can control other containersdocker run -it –v \ /var/run/docker.sock:/var/run/docker.sock bashapt-get install docker

• The container docker can control the host docker now• From there we can run a docker container in

the host and priv esc to root• Defense:

• Never mount the docker sock into the container

3. Device sharing• Docker supports directly passing a device into

a container• USB devices, bladeRF, whatever

docker run –it –-device=/dev/sda bash

• That container has full access to do whatever it wants to the device. • Reformat, inject commands, modify binaries,

etc• Defense:

• Don’t mount shared devices directly• Never run privileged containers

4. Shared Networking Exploits• Containers have a shared bridge interface named

docker0 with an individually namespaced network stack• The bridge interface docker0 will forward any packets

back up to eth0• By default all containers include the NET_RAW

capability• Result: A container can ARP poison entire network

segments and other containers• Defense:

• Manually drop the NET_RAW capability• Setup iptables rules to prevent these types of attacks• Use third party tools to manage networking

Honorable Mentions• 5. Kernel exploitation• 6. LXC 0-day• 7. Owning a service on the Docker Hub• 8. Docker service runs as HTTP by default• 9. Docker service does not verify TLS

certificates by default• 10. Sensitive environment variable

leakage

Recently Patched Examples• Privileged: SYS_RAWIO abuse (LXC only)

exploits unnecessary capabilities to get direct access to PCI devices• Privileged: Ptrace(2) lets a container

bypass seccomp-bpf policies because of a TOCTTOU issue• Unprivileged: PID namespace info-leak

of /proc/sched_debug contains namespace-unaware info to find other containers running

How to secure docker• Never run privileged containers!• AppArmor and Seccomp-bpf profiles• Defaults are good enough• Custom policies for your container would be

even better• GRSEC/PAX: Last line of defense in the

case of a kernel exploit

“However, for those that depend on VMs for security, Docker is not an alternative, but a complement”

@ewindisch – Cloud pioneer

Much security such wow

Bsidesroc.comwordpress

Antitree.comwordpress

Joethecoolestguyontheinternet.com

Jwilder/nginx-proxy

Antitree.comMySQL

Bsidesroc.comMySQL

Static HTML

Jrcs/lets-encrypt-nginx-proxy-companion443/TCP

443/TCP

443/TCP

443/TCP

briancranston 9030/TCP

$3.29/mo

$3.29/mo

$3.29/mo

$3.29/mo

$3.29/mo

Y U CONTAINER?

Bsidesroc.comwordpress

Antitree.comwordpress

Joethecoolestguyontheinternet.com

Jwilder/nginx-proxy

Antitree.comMySQL

Bsidesroc.comMySQL

Static HTML

Jrcs/lets-encrypt-nginx-proxy-companion443/TCP

443/TCP

443/TCP

443/TCP

briancranston 9030/TCP

$3.29/mo

$3.29/mo

$3.29/mo

$3.29/mo

$3.29/mo

“Fuck Docker” - JasonSecure, but not by default