Capsule8 Blog

Keep in mind that this article is specifically discussing defaults, though, not necessarily the overall potential for security hardening. There are certainly some security-related features FreeBSD is missing when compared to other BSDs (OpenBSD) or Linux distributions, but some of what is called out can absolutely be accomplished by system administrators after installation, or as part of image deployment… but it would be better if the defaults evolved to be more secure without extra configuration. As general purpose operating systems go, there was another interesting article from earlier this year comparing popular Linux distros which found that Ubuntu (18.04) had the best overall posture with regard to use of hardening and mitigation mechanisms out-of-the-box vs. versions of CentOS/RHEL, Debian, and OpenSUSE at the time. Some of this was due to the newer Linux kernel version being used, but also thanks to hardening of binaries, etc. > Our experiments indicate that Ubuntu 18.04 shows the largest adoption of OS and application-level mitigations, followed by Debian 9. https://capsule8.com/blog/millions-of-binaries-later-a-look-into-linux…

Yes. It happened before, so it was not exactly hard to guess. https://capsule8.com/blog/exploiting-systemd-journald-part-1/

The issue here with containers in general is that they break well known security boundaries. This is exacerbated by things like k8s cause it is inherently built to orchestrate many of them and assumes that there is a multi-tenant deployment by default. Most recently Google themselves wrote about this just a few weeks ago: https://cloud.google.com/blog/products/containers-kubernetes/kubernete… but the issues have been present forever: https://capsule8.com/blog/oomypod-nothin-to-cri-o-bout/ https://www.zdnet.com/article/doomsday-docker-security-hole-uncovered/ https://www.zdnet.com/article/alpine-linux-docker-images-ship-a-root-a…

The labs team at work wrote a bit [0] about why this is over-hyped (more context in the full post): > Arbitrary code execution is bad! But exploiting this vulnerability requires local access at a minimum, compounded by the attacker needing to exploit a relevant device to gain a foothold on the system. This list of valid footholds is quite limited. For instance, an attacker would need to perform code execution in the ISH or other Platform Controller Hub (PCH) devices — exploiting PCIe devices (like GPUs or RAID controllers) wouldn’t suffice. Additionally, per the original blog post, other methods of exploitation require physical access. Either way, this is limited to incredibly motivated and well-resourced attackers (like a nation-state with a high-value target identified). [0] https://capsule8.com/blog/ramming-down-hype-via-intel-csme/

Yep, VMs are safer than containers, because there is a larger barrier between the possibly malicious code running inside the VM than there is in the container context. A container is just another process, bound by limitations via namespaces and cgroups -- running on a shared kernel as a host. But don't take my word for it: > Simply put, containers are just processes, and as such they are governed by the kernel like any other process. Thus any kernel-land vulnerability which yields arbitrary code execution can be exploited to escape a container. To demonstrate this, Capsule8 Labs has created an exploit that removes the process from its confines and gives it root access in the Real World. Let’s take a look at what was involved. (I don't know much about capsule8 as a company is but that article[0] is pretty informative and seems spot on from what I read) If you can infiltrate a process (let's say a web server) running in a container and know a kernel exploit that can be used to get past these limitations (a "container escape"), then you can use them and get root on the main system. If that same process was running in a VM (without a container), you need to: - Infiltrate the process - Kernel exploit to gain root (assuming the program wasn't running under it) in the VM - Escape the VM (i.e. use the kernel or whatever else to actually break past the barriers of the hypervisor which was running the vm -- qemu +/- kvm, hyperv,etc) -- aka a "virtual machine escape"[1] - Gain…