Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-10-17T14:49:29Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2024configure does not find speex when using non-standard prefix2018-10-17T14:49:29ZRoland Hermansconfigure does not find speex when using non-standard prefixI tried to compile icecast 2.4.0 using a non-standard prefix as follows:
```
./configure --prefix=<mydir>
```
The libraries libogg, libvorbis and libtheora are found, but libspeex is not:
```
checking for libogg... ok
checking for lib...I tried to compile icecast 2.4.0 using a non-standard prefix as follows:
```
./configure --prefix=<mydir>
```
The libraries libogg, libvorbis and libtheora are found, but libspeex is not:
```
checking for libogg... ok
checking for libvorbis... ok
checking for libtheora... ok
checking for libspeex... configure: WARNING: Speex support disabled!
```
The reason for this is that the configure script does not append SPEEX_CFLAGS to CPPFLAGS. Attached patch contains a fix for m4/speex.m4 that temporarily modifies CPPFLAGS in a way similar to the other libraries.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2450a potential bug of NPD2022-09-06T00:08:21Zash1852a potential bug of NPDHi, I found a potential null pointer dereference bug in the project source code of icecast-Server, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps th...Hi, I found a potential null pointer dereference bug in the project source code of icecast-Server, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the red arrows represent the control flow,the file path can be seen in the blue framed section.
![image](/uploads/92074055051bc53bda3046f7bc09838d/image.png)
Although the code shown is for the latest but is still exist in current version. (https://gitlab.xiph.org/xiph/icecast-server/-/blob/master/src/format_ogg.c#L452-L454)
would you can help to check if this bug is true?thank you for your effort and patience!Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2396Unifiy <xsl:output>-settings for web/ and admin/2020-10-09T16:38:28ZPhilipp SchafftUnifiy <xsl:output>-settings for web/ and admin/`<xsl:output>`-settings must match web/ and admin/ as they share some templates.`<xsl:output>`-settings must match web/ and admin/ as they share some templates.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2377Icecast leaks memory in speex module when probing for codecs2019-06-28T08:06:23ZPhilipp SchafftIcecast leaks memory in speex module when probing for codecsIcecast currently leaks memory in codec probing within the speex module. This happens if the initial packet has less then 80 bytes.Icecast currently leaks memory in codec probing within the speex module. This happens if the initial packet has less then 80 bytes.Philipp SchafftPhilipp Schafft2019-06-28https://gitlab.xiph.org/xiph/icecast-server/-/issues/2373Incorrect status code2020-10-15T16:20:55ZPhilipp SchafftIncorrect status codeIn case of 'mountpoint will not accept URL updates' and other admin errors Icecast might send incorrect HTTP status headers.
This happens at least in branch ph3-mdoule-client-tests.In case of 'mountpoint will not accept URL updates' and other admin errors Icecast might send incorrect HTTP status headers.
This happens at least in branch ph3-mdoule-client-tests.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2372Icecast 'locks up' on SIGHUP if there are duplicate listener-sockets in the c...2020-10-10T10:13:32ZThomas B. RückerIcecast 'locks up' on SIGHUP if there are duplicate listener-sockets in the configAs reported by 'szett' on IRC.
Excerp of the offending config file:
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</li...As reported by 'szett' on IRC.
Excerp of the offending config file:
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>
<!-- SOCKET FOR SOURCES -->
<listen-socket>
<port>8000</port>
<!-- <bind-address>127.0.0.1</bind-address> -->
<!-- <shoutcast-mount>/stream</shoutcast-mount> -->
</listen-socket>Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2370Url events don't work when an "action" option is configured2019-02-02T04:30:49Zspr0cketeerUrl events don't work when an "action" option is configured```
<event-bindings>
<event type="url" trigger="source-connect">
...
...
<option name="action" value="mount_add" />
```
Bug is in event_url.c:event_get_url()
https://gitlab.xiph.org/xiph/icecast-server/blob/master/s...```
<event-bindings>
<event type="url" trigger="source-connect">
...
...
<option name="action" value="mount_add" />
```
Bug is in event_url.c:event_get_url()
https://gitlab.xiph.org/xiph/icecast-server/blob/master/src/event_url.c#L134
Should be `free(self->action)` not `free(self->url)`https://gitlab.xiph.org/xiph/icecast-server/-/issues/2366Icecast does list POST support for Admin interface but has it disabled for le...2019-02-02T04:30:49ZPhilipp SchafftIcecast does list POST support for Admin interface but has it disabled for legacy-global-sourceIcecast lists POST support in it's Allow. However it is by default disabled for legacy-global-source on admin/. POST should be allowed as well.Icecast lists POST support in it's Allow. However it is by default disabled for legacy-global-source on admin/. POST should be allowed as well.Philipp SchafftPhilipp Schafft2018-12-14https://gitlab.xiph.org/xiph/icecast-server/-/issues/2356Icecast does not handle HTTP Upgrade as to RFC2018-12-14T03:48:15ZPhilipp SchafftIcecast does not handle HTTP Upgrade as to RFCCurrently Icecast 2.5.x does not handle HTTP upgrades correctly. It does not send the final reply to the request doing the upgrade.Currently Icecast 2.5.x does not handle HTTP upgrades correctly. It does not send the final reply to the request doing the upgrade.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2355DoS vector using incorrect TLS teardown2018-12-07T13:48:18ZPhilipp SchafftDoS vector using incorrect TLS teardownWhen in a TLS SOURCE connection the socket is closed without TLS teardown Icecast will read from the socket in a tight endless loop. This locks up the corresponding thread.
Affected at least: Icecast 2.4.4, Icecast 2.5 beta 2.
May be re...When in a TLS SOURCE connection the socket is closed without TLS teardown Icecast will read from the socket in a tight endless loop. This locks up the corresponding thread.
Affected at least: Icecast 2.4.4, Icecast 2.5 beta 2.
May be related to OpenSSL version. Tested with version 1.0.1t.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2342Security vulnerability: buffer overflow in URL authentication allows remote c...2018-11-05T08:00:08ZNick RolfeSecurity vulnerability: buffer overflow in URL authentication allows remote code executionHello,
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,
sizeo...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 TeamThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2336Icecast 2.5.x relays not working2018-07-26T10:19:39ZPhilipp SchafftIcecast 2.5.x relays not workingRelays do not work.
In master since 4a10d7e74422b7c3a31d4677e12f5aa3ce52474f.
client->request_body_length is not correctly set up leading to body read limit (client->request_body_length=0). client generally may not be in correct state.Relays do not work.
In master since 4a10d7e74422b7c3a31d4677e12f5aa3ce52474f.
client->request_body_length is not correctly set up leading to body read limit (client->request_body_length=0). client generally may not be in correct state.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2335`<no-mount>` (`<mount>`'s child) is noop in 2.5.x2021-04-14T10:51:43ZPhilipp Schafft`<no-mount>` (`<mount>`'s child) is noop in 2.5.xThe tag `<no-mount>` (which is a child element of `<mount>`) doesn't seem to do anything in 2.5.x. However according to source code comment it should disallow direct access to the mount.
This may interact with the ACL system.The tag `<no-mount>` (which is a child element of `<mount>`) doesn't seem to do anything in 2.5.x. However according to source code comment it should disallow direct access to the mount.
This may interact with the ACL system.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2328When configuration file is invalid, icecast hangs indefinitely2018-06-16T20:30:29ZMarcin LewandowskiWhen configuration file is invalid, icecast hangs indefinitelyI am running icecast 2.4.3 on ubuntu 16.04, compiled from sources.
I have found out that if given XML config has invalid syntax, it outputs error but do not terminate the process. It is quite painful as it is not easily possible to chec...I am running icecast 2.4.3 on ubuntu 16.04, compiled from sources.
I have found out that if given XML config has invalid syntax, it outputs error but do not terminate the process. It is quite painful as it is not easily possible to check if service is running or not, as process exists.
```
/usr/bin/icecast -c /etc/icecast/icecast.xml
/etc/icecast/icecast.xml:1: parser error : Document is empty
FATAL: error parsing config file (/etc/icecast/icecast.xml)
XML config parsing error
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2008A hang in send_ogg_headers()2020-02-14T13:10:21ZartemA hang in send_ogg_headers()I've recently had the following hang of icecast2 server. Not sure if it's the first time, but it's pretty rare anyway, so i can't reliably reproduce, but this time i managed to debug a little.
I'm running on ubuntu 12.04 vps with defaul...I've recently had the following hang of icecast2 server. Not sure if it's the first time, but it's pretty rare anyway, so i can't reliably reproduce, but this time i managed to debug a little.
I'm running on ubuntu 12.04 vps with default package (icecast2-2.3.2-9ubuntu1), didn't try to pull the latest svn version yet.
```
$ tail /var/log/icecast2
...
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
...
```
```
$ strace -p `pidof icecast2` -f 2>&1 | grep send
...
[pid 26113] send(14, 0x5ff8e559, 2406954578, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e558, 2406954579, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e557, 2406954580, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e556, 2406954581, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e555, 2406954582, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e554, 2406954583, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e553, 2406954584, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e552, 2406954585, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e551, 2406954586, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e550, 2406954587, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e54f, 2406954588, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e54e, 2406954589, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e54d, 2406954590, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e54c, 2406954591, 0) = -1 EPIPE (Broken pipe)
...
```
You may notice how buffer address decreases by 1 and buffer length increases by 1 on every line; no other `send()` calls happen, so i could easily backtrace them:
```
$ gdb -p `pidof icecast`
...
Breakpoint 1, 0xb7461e40 in send () from /lib/i386-linux-gnu/tls/i686/nosegneg/libpthread.so.0
(gdb) bt
#0 0xb7461e40 in send () from /lib/i386-linux-gnu/tls/i686/nosegneg/libpthread.so.0
#1 0x08067c40 in sock_write_bytes (sock=14, buff=0x5f08fe9d, len=2422676750) at sock.c:360
#2 0x0804f9aa in connection_send (con=0x9748ac8, buf=0x5f08fe9d, len=2422676750) at connection.c:303
#3 0x08058d20 in client_send_bytes (client=0x9740a38, buf=0x5f08fe9d, len=2422676750) at client.c:202
#4 0x0805e6c2 in send_ogg_headers (headers=0xb666e848, client=0x9740a38) at format_ogg.c:500
#5 write_buf_to_client (client=0x9740a38) at format_ogg.c:534
#6 0x08054f57 in send_to_listener (deletion_expected=0, client=0x9740a38, source=0xb647c7d8) at source.c:544
#7 source_main (source=0xb647c7d8) at source.c:716
#8 0x0805564f in source_client_thread (arg=0xb647c7d8) at source.c:1225
#9 0x08068b2f in _start_routine (arg=0xb6674970) at thread.c:655
#10 0xb745ad4c in start_thread () from /lib/i386-linux-gnu/tls/i686/nosegneg/libpthread.so.0
#11 0xb7398ace in clone () from /lib/i386-linux-gnu/tls/i686/nosegneg/libc.so.6
...
```
Thomas B. RückerThomas B. Rücker