2. Disclaimer: I’m using Docker
wrong
Let 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.
9. Containers today vs yesterday
Today
• 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
11. 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
12. 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?
13. 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
14. 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
15. 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 terminal
deny mount fstype=devpts
• Example: Utility access
• Block access to /proc/sys/kernel/modprobe so that
attackers can’t replace it with arbitrary code
deny /proc/sys/kerne[^l]*{,/**} wklx,
16. 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
17. The Root Threat
A 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
18. 1. RW Volume Abuse
• Containers allow you to mount a host volume
inside of a container
docker 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
19. 2. Docker socket control
• Some containers will mount the Docker socket
so it can control other containers
docker run -it –v
/var/run/docker.sock:/var/run/docker.sock bash
apt-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
20. 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
21. 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
22. 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
23. 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
24. 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
25. “However, for those that
depend on VMs for
security, Docker is not an
alternative, but a
complement”
@ewindisch – Cloud pioneer
26. Much security such wow
Bsidesroc.com
wordpress
Antitree.com
wordpress
Joethecoolestguyontheinternet.com
Jwilder/nginx-proxy
Antitree.com
MySQL
Bsidesroc.com
MySQL
Static
HTML
Jrcs/lets-encrypt-nginx-proxy-companion
443/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