The IDEs of March
This is a collection of things related to my presentation "The IDEs of March", presented at CrikeyCon and AusCERT in 2019.
Abstract
Software is "eating the world", and in the era of DevOps, those who are cutting the code often have privileged access to production systems and software delivery pipelines. A developer's workstation is a fantastic place for an adversary to "be" in 2019.
We're relentlessly and rightfully focused on secure design, code quality, and killing bugs. Are we hearing the call to protect the people and systems responsible for building and operating our squeaky clean code?
Through a in-depth breakdown of security bugs in client-side software development tooling (which are used by developers and hackers alike) and some crazy arm-waving and posturing about the CI/CD's and the Jenkinses, we'll explore the insecurities of software development software. How might an attacker gain control over a developer's workstation? What might they do once they pop shell? And what can we possibly do to pursue business excellence through end-to-end secure delivery of software?
Contents:
the_ides_of_march.pdf
- presentation slidesdemo_rvm_bugs
- Docker image for RVM demodemo_vscode_workspace_git
- Docker image for Visual Studio Code demodemo_end_to_end
- Docker-compose setup for end-to-end demodocker_vscode
- Docker image for the latest Visual Studio Code, some batteries included
SYS_PTRACE
capability
A warning regarding X and the The instantiate.py
scripts included in this repository run Docker containers
with one or both of the following:
- The
SYS_PTRACE
capability to allow debugging and tracing of processes within the container - Your X socket exposed to the contaner
The SYS_PTRACE
capability might allow any malware within the Docker
container to unduly influence your host OS, or even to escape the container
entirely.
The X socket exposure definitely allows any malware within the Docker container to unduly influence your host OS and to escape the container through tricksy X gymnastics. See https://youtu.be/o5cASgBEXWY?t=1011 for more on this sorcery (hi metl)
The demo_rvm_bugs
and demo_vscode_workspace_git
Docker image specifications
do not contain malware, but they intentionally include old and vulnerable
software for demonstration purposes.
The demo_end_to_end
Docker image specification contains exploits that
should not be dangerous - all of their activity should be confined to the
Docker-compose containers.
The docker_vscode
contains no malware, nor any exploits, but you know. This
talk is all about vulnerabilities in software development software after all.
That said, the X socket exposure is almost certainly better than just running
VSCode directly on your host OS.
All code and all Docker image specifications are provided "as is" with no warranties or guarantees.
A note regarding SELinux and .Xauthority
These Docker images and the accompanying instantiate.py
scripts were
developed and tested on a Debian Stretch host.
Some people have reported issues with the X exposure on other OS's such as Fedora.
Some of these issues appear to relate to SELinux. See https://adam.younglogic.com/2017/01/gui-applications-container/ for potential guidance on that front.
Some of these issues appear to relate to X requiring authentication via magic cookies. See the following links for potential guidance on that front.
- https://stackoverflow.com/a/51795708; which references:
- https://stackoverflow.com/a/25280523
docker_vscode/instantiate.py
has a -x
or --xauthority
flag that attempts
to implement the fix in the second link above. It may be of use if launching
code
inside the container seems to do nothing.
It is not implemented for the demos. Doing so is an exercise left for the reader :^)