Security vulnerability: buffer overflow in URL authentication allows remote code execution
I would like to report a security vulnerability in the Icecast server.
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
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.
Our automated analysis highlighted this bug, and another similar misuse of
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
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
--Nick Rolfe, Semmle Security Research Team