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?
It has been a while since the Git vulnerability was announced. The major public repository providers have long since been preventing hosting repositories serving CVE-2018-11235.
Recently I was working on a git repository that contained numerous submodules. At this point I realised that I did not know how submodules worked and decided to dive into the submodule system to gain a better understanding. During this process of discovery I came across a vulnerability in the submodule system, which lead to Remote Code Execution (RCE) in git when a submodule was initialised. This allowed for reliable exploitation of the host that was cloning my malicious repository, and ultimately gave me RCE in GitHub Pages and CVE-2018-11235 for git.
The FTP library in Ruby did not validate remote filenames and blindly passed these to the
kernel.open function. This created a remotely exploitable vulnerability. Since the filenames were supplied by the remote FTP server, it was possible to create a malicious server that could exploit this vulnerability when a vulnerable Ruby client connected and tried to download a file.
“GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data” - graphql.org The GraphQL query language allows developers to easily write front-end queries, using a JSON like syntax, to retrieve data from the back-end. The big plus here that a single API end-point can return multiple types and formats of data based on the contents of the query. This simplicity has resulted in a steady adaption of GraphQL.