Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-06-16T20:30:29Zhttps://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/794[PATCH] Autotools and header fixes2018-06-15T21:35:52Zgtgbr[PATCH] Autotools and header fixes* Improve autotools handling of sys/time.h and time.h -- it should be checked whether both may be included simultaneously.
* Actually use the XIPH_C__FUNC__ macro, since #ifdef __SUNPRO_C was removed from src/compat.h
* A bit of header...* Improve autotools handling of sys/time.h and time.h -- it should be checked whether both may be included simultaneously.
* Actually use the XIPH_C__FUNC__ macro, since #ifdef __SUNPRO_C was removed from src/compat.h
* A bit of header/includes cleanup. Icecast sources search for support libs locally first, not in system include paths.
* Remove spurious CRs
* Do not let Windows include <stdio.h> twice in src/util.cMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/595fallback management in /admin/ interface2018-06-15T21:35:14ZMike Altrionfallback management in /admin/ interfaceIt would be nice to see and manage in the admin interface what fallback mountpoint was configured for a given mountpoint.It would be nice to see and manage in the admin interface what fallback mountpoint was configured for a given mountpoint.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2147Split up Icecast certificate handling into private and public key files2018-06-15T21:17:45ZThomas B. RückerSplit up Icecast certificate handling into private and public key filesThis would make it easier for people who are used to most software requiring two files, also it would make it easier to share certificate files with other server software like e.g. Apache httpd or dovecot imapd.This would make it easier for people who are used to most software requiring two files, also it would make it easier to share certificate files with other server software like e.g. Apache httpd or dovecot imapd.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2202Hardcoded HTTP protocol verification for master-slave relaying2018-06-15T20:53:24ZMarvin ScholzHardcoded HTTP protocol verification for master-slave relayingIf using master slave relaying, Icecast tries to download a .txt file with an overview of the mountpoints connected on the master. There the code has a hardcoded check for "HTTP/1.0", that means it will fail if Icecast ever uses HTTP/1.1...If using master slave relaying, Icecast tries to download a .txt file with an overview of the mountpoints connected on the master. There the code has a hardcoded check for "HTTP/1.0", that means it will fail if Icecast ever uses HTTP/1.1 instead, which is not very good.
A proper check should be used there.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2245Move TLS options out of <paths>2018-06-15T20:50:30ZPhilipp SchafftMove TLS options out of <paths>The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2258Absolute paths when relaying2018-06-15T20:47:52ZmschmidAbsolute paths when relayingI've set up a couple of relays that were/still are properly running under icecast 2.3.2 with its separate mount point configuration, while they do not work under 2.4.0 and later.
The problem seems to be tied to how the client's requests ...I've set up a couple of relays that were/still are properly running under icecast 2.3.2 with its separate mount point configuration, while they do not work under 2.4.0 and later.
The problem seems to be tied to how the client's requests are interpreted. On the newer version it seems to be forbidden to request the full path, while the old did support this. But relays always create the full path in the links.
the server'n name is 'mediaserv'.
the paths are configured like this (debian defaults, no chroot):
<basedir>/usr/share/icecast2</basedir>
<logdir>/var/log/icecast2</logdir>
<webroot>/usr/share/icecast2/web</webroot>
<adminroot>/usr/share/icecast2/admin</adminroot>
a relay example is:
<relay>
<server>mms-live.online.no</server>
<port>80</port>
<mount>/p4_norge_mp3_hq</mount>
<local-mount>/p4</local-mount>
<on-demand>1</on-demand>
<relay-shoutcast-metadata>1</relay-shoutcast-metadata>
</relay>
The content of
http://mediaserv:8000/usr/share/icecast2/web/p4.m3u
is:
http://mediaserv:8000/usr/share/icecast2/web/p4
which does no longer work.
When I reduce it to http://mediaserv:8000/p4, it's working perfectly.
Shouldn't all the links be relative?
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2269Allow certificate rotation2018-06-15T20:37:13ZFinnAllow certificate rotationI'd like to re-issue my SSL certs somewhat frequently and have Icecast reload them without kicking off all my users. Perhaps with a SIGHUP?
Specifically, I'm using Let's Encrypt which automatically re-issues certs every 90 or so days, a...I'd like to re-issue my SSL certs somewhat frequently and have Icecast reload them without kicking off all my users. Perhaps with a SIGHUP?
Specifically, I'm using Let's Encrypt which automatically re-issues certs every 90 or so days, and it'd be nice to be able to set Icecast on a cronjob to re-read them after they get reissued.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2247XSLs are returned in plaintext if trailing dot is appended to the URL (Window...2018-04-16T22:12:13ZMarvin ScholzXSLs are returned in plaintext if trailing dot is appended to the URL (Windows only)If requesting an xsl file, anyone can get a unprocessed version of that file, possibly exposing internal information to the user, by appending a dot to the requested filename:
```
http://localhost:8000/status.xsl.
```
Only Windows is...If requesting an xsl file, anyone can get a unprocessed version of that file, possibly exposing internal information to the user, by appending a dot to the requested filename:
```
http://localhost:8000/status.xsl.
```
Only Windows is affected. This is due to the way the Windows API handles filenames, as it strips the trailing dot and will assume status.xsl instead of the version with the trailing dot.
*Unix and Linux builds were never affected.*
(See CVE-2005-0837 and #635)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2191Icecast can be crashed remotely if stream_auth is enabled.2018-04-16T22:12:13ZThomas B. RückerIcecast can be crashed remotely if stream_auth is enabled.Downstream bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782120
Icecast can be killed by anyone with a simple HTTP request when
<authentication type="url"> is used and a stream_auth handler is
defined.
Example configura...Downstream bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782120
Icecast can be killed by anyone with a simple HTTP request when
<authentication type="url"> is used and a stream_auth handler is
defined.
Example configuration:
```
<mount>
<mount-name>/test.ogg</mount-name>
<authentication type="url">
<option name="stream_auth" value="http://localhost/auth"/>
</authentication>
</mount>
```
Proof of concept exploit:
```
curl "http://stream.example.org:8000/admin/killsource?mount=/test.ogg"
```
This happens if no logon credentials are sent with the request. The crash happens regardless of a source client being connected to the vulnerable mountpoint.
This will be released in a security release 2.4.2 today.
CVE-2015-3026Icecast 2.4.2Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2255Invalid XML in Icecast statistics output due to lack of escaping2018-04-16T22:12:13ZThomas B. RückerInvalid XML in Icecast statistics output due to lack of escapingIcecast version 2.3.3-2ubuntu1.14.04.1 , when reporting statistics via API calls to http://%s:%d/admin/stats.xml, returns this invalid XML:
```
<icestats>
<source mount="/radio">
<Listeners>1</Listeners>
<listener>
<IP>23.2.9...Icecast version 2.3.3-2ubuntu1.14.04.1 , when reporting statistics via API calls to http://%s:%d/admin/stats.xml, returns this invalid XML:
```
<icestats>
<source mount="/radio">
<Listeners>1</Listeners>
<listener>
<IP>23.2.9.2</IP>
<UserAgent>Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12F70 [FBAN/FBIOS;FBAV/46.0.0.54.156;FBBV/18972819;FBDV/iPhone5,3;FBMD/iPhone;FBSN/iPhone OS;FBSV/8.3;FBSS/2; FBCR/AT&T;FBID/phone;FBLC/en_US;FBOP/5]</UserAgent>
<Connected>0</Connected>
<ID>2634887</ID>
</listener>
</source>
</icestats>
```
Note the unescaped &T; which is an undefined XML entity "T", and causes parsers to explode.
Expected behavior: text inside blocks should be html escaped or enclosed in a CDATA block, if I remember my XML correctly.
[Originally reported on github](https://github.com/xiph/Icecast-Server/issues/3) by [kenrestivo](https://github.com/kenrestivo)Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2199Icecast listener count negative under special circumstances2018-04-16T14:24:46ZMarvin ScholzIcecast listener count negative under special circumstancesAs reported by SimAV on IRC (thanks a lot), it can happen under special circumstances that the Icecast global listener count becomes a negative number.
It seems this is a very special case where `format_check_http_buffer` has an interna...As reported by SimAV on IRC (thanks a lot), it can happen under special circumstances that the Icecast global listener count becomes a negative number.
It seems this is a very special case where `format_check_http_buffer` has an internal problem (see log). As far as I have investigated, this is caused because `ebml_create_client_data` returns -1. We need to investigate why this leads to a wrong listener count.
Some more information attached.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/402two different segfaults with statically linked icecast2018-03-06T12:50:22Zgtgbrtwo different segfaults with statically linked icecast```
My plan was to make a statically linked icecast binary, that also incorporates
libc and friends - it's supposed to be autonomous. Note that these segfaults do
not happen when the standard libs are dynamically linked (ogg, vorbis, l...```
My plan was to make a statically linked icecast binary, that also incorporates
libc and friends - it's supposed to be autonomous. Note that these segfaults do
not happen when the standard libs are dynamically linked (ogg, vorbis, libxml2
and libxslt always being statically linked into icecast, because i don't want to
keep the whole build environment + libs all the time in my homedir).
What I did was simply add the parameter -static to the final gcc line, when the
binary gets linked. All libs from elsewhere and Xiph are either the latest
release (libiconv, libxml, ...) or today's CVS (2003-07-07, ogg, vorbis,
icecast)
#1
Built on some Redhat Linux with gcc 2.96 (blegh) and gcc 3.1 (blegh), with
identical effect, making me believe that it's not a compiler bug for a change.
Maybe it's a crappy libc... This segfault is minor, because it happens when the
server is terminated with a SIGTERM, i.e. a CTRL-C. A SIGABRT doesn't trigger
the segfault. Maybe it's a hidden memory leak as well? Here's the backtrace:
#0 0x0811b778 in chunk_free ()
#1 0x0811deed in free ()
#2 0x080c2a81 in xmlCleanupGlobals () at globals.c:49
#3 0x080882cb in xmlCleanupParser () at parser.c:11179
#4 0x0804a050 in main (argc=3, argv=0x8283080) at main.c:105
#5 0x0810a53a in __libc_start_main ()
#2
Built on a current Gentoo Linux, also against libraries in my homedir to avoid
the -O3 -mcpu... optimizations everywhere and possible breakage that comes with
it. This would be gcc 3.2.2. Not tested with stdlibs linked dynamically, but
this happens when a source connects to the statically linked server, running on
the same Redhat box from segfault #1:
#0 0x081bf7e8 in strcasecmp ()
#1 0x0805a14f in httpp_parse (parser=0x83fbb08,
http_data=0xbf3feacc "SOURCE /kolaradio.ogg HTTP/1.0\nAuthorization: Basic
c291cmNlOnNpbXB1bHNlOQ==\nice-name: KOLAradio test stream\nice-genre:
misc\nice-audio-info: samplerate=44100;channels=2;quality=1%2e00\nice-public:
0\nic"..., len=291) at httpp.c:370
#2 0x0804ce0a in _handle_connection (arg=0x0) at connection.c:910
#3 0x080593d4 in _start_routine (arg=0x83e7b40) at thread.c:654
#4 0x0819cd3d in pthread_start_thread ()
patient: "Doctor! It hurts when I do this!"
patient: *pokes own eye* / *links statically*
doctor: "Then don't do it!"
Yeah, I know, that's why this isn't very serious. ;) I'd like to see this
working, despite the limited use for entirely static binaries, so if someone
finds the time to look into this, I'd appreciate that a lot.
Thanks,
Moritz
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/425http_proxy YP2018-03-06T12:50:22ZGitlab Bothttp_proxy YP```
Currently icecast2 only allows you to directly connect to the yp server(s), it
would be useful to me if there was a way to connect via a http proxy server.
``````
Currently icecast2 only allows you to directly connect to the yp server(s), it
would be useful to me if there was a way to connect via a http proxy server.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/429moveclients command problem2018-03-06T12:50:22Zvalen_23moveclients command problem```
In my ices configuration file, I have ices sending two streams to the same
icecast server (i.e. /eg1.ogg and /eg2.ogg). If I use the moveclients command
to move all the listeners from /eg1.ogg to /eg2.ogg, the listeners get garble...```
In my ices configuration file, I have ices sending two streams to the same
icecast server (i.e. /eg1.ogg and /eg2.ogg). If I use the moveclients command
to move all the listeners from /eg1.ogg to /eg2.ogg, the listeners get garbled
audio data. However, I am able to move listeners to a stream from a different
ices streamer without any problems. It's only when I try to move users to a
different stream from the same streamer do I get this problem.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/473Decoders quit after ~ 4 hours2018-03-06T12:50:22Zl.imminkDecoders quit after ~ 4 hours```
all vorbis based decoders close after listening to an icecast server (all
versions) after ~ 4 hours. I've tested ogg123, mplayer, foobar2000 and winamp,
with the icecast server on both a local system as on the internet. I've tested
o...```
all vorbis based decoders close after listening to an icecast server (all
versions) after ~ 4 hours. I've tested ogg123, mplayer, foobar2000 and winamp,
with the icecast server on both a local system as on the internet. I've tested
ogg123 with both the standard tcp/ip stack and netcat but all quit after ~ 4
hours. The decoders quit because they get an end of file request. In the icecast
server log the message DBUG format/format_generic_write_buf_to_client Client had
recoverable error -1 occurs. Still the server continues to play. After the
decoder is resetted it continues it normal operation.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/504Relayed streams not added to stream directories2018-03-06T12:50:22ZmarkRelayed streams not added to stream directories```
In my testing, relayed streams are not being added to the various stream
directories.
An additional minor problem is that current song of relayed streams does not
show up on the /status.xsl page.
``````
In my testing, relayed streams are not being added to the various stream
directories.
An additional minor problem is that current song of relayed streams does not
show up on the /status.xsl page.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/632Incorrect Base64 decoder in utils (missing '2018-03-06T12:50:22ZGitlab BotIncorrect Base64 decoder in utils (missing '*Base64 utils. Encode is ok, but decode? '=' is missed, so, VLC, that
contains correct base64 encoder, produces '=' at the end of the string.
We need to pacth that case in decoder:
char *util_base64_decode(unsigned char *input)
{
...*Base64 utils. Encode is ok, but decode? '=' is missed, so, VLC, that
contains correct base64 encoder, produces '=' at the end of the string.
We need to pacth that case in decoder:
char *util_base64_decode(unsigned char *input)
{
int len = strlen(input);
char *out = malloc(len*3/4 + 5);
char *result = out;
signed char vals[4];
while(len > 0) {
if(len < 4 && *input != '=')
{
free(result);
return NULL; /* Invalid Base64 data */
} else if (*input == '=') break;
Icecast 2.3Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/508YP can keep source tree read lock for too long2018-03-06T12:50:22ZKarl HeyesYP can keep source tree read lock for too long```
yp_touch keeps rlock on source tree when updating YP directory servers, if one
of the stated YP servers becomes inaccessible then curl will block for upto 30
seconds per server per source. Any new source connecting or disconnecting ...```
yp_touch keeps rlock on source tree when updating YP directory servers, if one
of the stated YP servers becomes inaccessible then curl will block for upto 30
seconds per server per source. Any new source connecting or disconnecting will
block on the wlock until the yp thread finishes all existing YP source updates.
Test with a listening port that does not send anything back.
```Ed "oddsock" ZaleskiEd "oddsock" Zaleskihttps://gitlab.xiph.org/xiph/icecast-server/-/issues/633Client count in stats.xml continues to increase.2018-03-06T12:50:22ZJoel EbelClient count in stats.xml continues to increase.In stats.xml, the <icestats><clients> value continually increases. Every time I restart a source, this number goes up and never comes back down. Right now it's up to 432 even though I have a 100 client limit. It seems that when a sour...In stats.xml, the <icestats><clients> value continually increases. Every time I restart a source, this number goes up and never comes back down. Right now it's up to 432 even though I have a 100 client limit. It seems that when a source disconnects, this client value doesn't decrement, but when a listening client disconnects it does. There could be more to it than that, but that's what it appears to be to me.Michael SmithMichael Smith