This is going to be a short write-up about an interesting argument injection I ran into a while ago. There is nothing new here, but it is still worth looking at as argument injection is an oft overlooked attack avenue as everyone is going after the more traditional command injection vulnerabilities. What is argument injection? Very similar to command injection, argument injection occurs when attacker controlled values/text are passed into a shell function without adequate sanitization....

Earlier in the year, while doing some research for my talk at Troopers 2019, in which I examined build systems and the how git can cause security issues, I found a git related vulnerability in Docker. This vulnerability has since been assigned CVE-2019-13139 and was patched in the Docker engine update 18.09.4. The issue is a relative straight forward command injection, however, what possibly makes it a little more interesting is that it occurs in a Go code base....

Containers, Docker containers in particular, are deployed everywhere these days. This is especially true in build environments or your typical CI/CD pipeline. A frequent requirement in these environments is the ability to build Docker container images, which tends to introduce security vulnerabilities through misconfiguration. One typically finds that the docker daemon is exposed to allow for so-called docker-in-docker builds, which I’ve previously shown can easily lead to container breakout. This means I’m always on the lookout for possible places that the Docker daemon/API might be directly accessible....

Last year I stumbled across a vulnerability in Go’s go get command, which could lead to code execution when a malicious Go package was downloaded. I reported this to the Go team and it was subsequently assigned CVE-2018-16873. The actual vulnerability was really interesting since it was solely a logic vulnerability, where I abused the order in which packages were cloned by the go get command and how these would be laid out on disk. This makes it one of my personal favourite bugs. ...

Last year Luke Jahnke wrote an excellent blog post on the elttam blog about finding a universal RCE deserialization gadget chain for Ruby 2.x. In the post he discusses the process of finding and eventually exploiting a gadget chain for Marshal.load. I was curious if the same chain could be used with YAML.load. It has been shown before that using YAML.load with user supplied data is bad, but all the posts I could find focuses on Ruby on Rails (RoR). Wouldn’t it be nice to have a gadget chain to use in non-RoR applications? ...