Icecast-libshout issueshttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues2022-09-13T10:40:11Zhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2336a potential NPD in source file src/proto_http.c2022-09-13T10:40:11Zash1852a potential NPD in source file src/proto_http.cHi, I found a potential null pointer dereference bug in the project source code of libshout, 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 gen...Hi, I found a potential null pointer dereference bug in the project source code of libshout, 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 file path can be seen in the blue framed section.
![getvar](/uploads/d440a52b893294bb5844c94ffe3e2a93/getvar.jpg)
Although the code shown is for the latest but is still exist in current version.
What I'm confused about is, some empty judgment operation to return value of httpp_getvar can be found in some code snippets of the libshout project, so I'm not sure if the context of this snippet can assert that the call-statement won't return null, if so please give me some hints.thank you for checking if this bug is true.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2333Support 30X Redirects2021-11-18T14:26:16ZJamie WoodsSupport 30X RedirectsIt would be very useful for libshout to natively handle receiving 301/302 redirects, when connecting as a source.
This would allow various streaming applications to connect to a different Icecast instance dynamically (for example - regi...It would be very useful for libshout to natively handle receiving 301/302 redirects, when connecting as a source.
This would allow various streaming applications to connect to a different Icecast instance dynamically (for example - regional clusters of servers)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2327When preventing caller "abuse-after-free", abort()2023-03-09T09:48:58ZMoritz GrimmWhen preventing caller "abuse-after-free", abort()The shout_free() function attempts to prevent use-after-free issues by not doing anything in case the caller still has an open connection. While this can mitigate security issues in calling applications, it covers up these flaws in the f...The shout_free() function attempts to prevent use-after-free issues by not doing anything in case the caller still has an open connection. While this can mitigate security issues in calling applications, it covers up these flaws in the form of hard to detect memory leaks.
Libshout should either leave the responsibility for these kinds of defects where they belong and not perform the "is a connection still open?" check, as it will never be able to solve _all_ of these problems (and applications running into this _will_ have other problems as well and are in some dire need of SAST tools).
However, since there is some merit to this safeguard, at least make it highly visible with a proper, noisy abort(): [shout_free_abort_before_use-after-free.diff](/uploads/7eb49ff1ce810e41d523e54cbb6f8428/shout_free_abort_before_use-after-free.diff) -- it might be a wake-up call!https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2315Network socket not set to nonblocking mode despite using nonblocking API2020-10-23T07:06:28ZTomasz LemiechNetwork socket not set to nonblocking mode despite using nonblocking APIhttps://gitlab.xiph.org/xiph/icecast-libshout/commit/0ac7ed9e84c3871d4427acc1ce59dca5e4af21ef introduced a bug which causes network sockets not to be set into nonblocking mode when requested with `shout_set_nonblocking(s, 1)`. This can b...https://gitlab.xiph.org/xiph/icecast-libshout/commit/0ac7ed9e84c3871d4427acc1ce59dca5e4af21ef introduced a bug which causes network sockets not to be set into nonblocking mode when requested with `shout_set_nonblocking(s, 1)`. This can be demonstrated simply by tracing an example `nonblocking` app.
Bad (current master HEAD):
```
$ strace -f -e fcntl,fcntl64,socket,connect ./nonblocking
(...)
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
```
Good (v2.4.3):
```
(...)
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now i n progress)
```
In the first case `fcntl` is never called and the socket stays in the default (blocking) mode.
This is due to the following condition in `shout_connection_connect`:
```C
if (con->nonblocking == SHOUT_BLOCKING_DEFAULT)
shout_connection_set_nonblocking(con, shout_get_nonblocking(shout));
```
But as `con->nonblocking` is never initialized to this value, it's effectively `if(0)`.
Adding a simple:
```C
con->nonblocking = SHOUT_BLOCKING_DEFAULT;
```
to `shout_connection_new` fixes the problem. But this turns the above condition into `if(1)`, so is it really needed? It was not there before. What's the idea behind this?https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2312Use-after-free bug after reopening connection2020-10-21T08:50:27ZAlexander MilosUse-after-free bug after reopening connectionHello,
There have recently been some issues when using libshout in combination with MPD (the Music Player Daemon) which, after some investigation in collaboration with the author of MPD, have apparently been tracked to a bug in libshout...Hello,
There have recently been some issues when using libshout in combination with MPD (the Music Player Daemon) which, after some investigation in collaboration with the author of MPD, have apparently been tracked to a bug in libshout. MPD's author reported the issue but did so on your GitHub mirror, so in case you may have missed it I saw fit to report it here as well.
The gist of that bug report is as follows:
"Since libshout 2.4.2, the library crashes due to a use-after-free and double-free bug if an application reopens the connection using shout_open() after a previous connection with the same shout_t had been closed by shout_close().
See [MusicPlayerDaemon/MPD#622](https://github.com/MusicPlayerDaemon/MPD/issues/622) for details and valgrind logs.
The crash bug was introduced by commit 3110fe32"
The original bug report is here: [xiph/Icecast-libshout#17](https://github.com/xiph/Icecast-libshout/issues/17)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2311Add support for JWT tokens2023-03-18T10:25:44ZThiago SantosAdd support for JWT tokensAdds support for setting a JWT authorization token (or any opaque token) to libshout. It will be used as an "Authorization: Bearer <token>" header instead of the usual user/password header for HTTP requests.Adds support for setting a JWT authorization token (or any opaque token) to libshout. It will be used as an "Authorization: Bearer <token>" header instead of the usual user/password header for HTTP requests.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2308Source clients experience issues with 2.4.2 and latest release 2.4.32020-02-17T20:23:01ZThomas B. RückerSource clients experience issues with 2.4.2 and latest release 2.4.3Migrated from GitHub: https://github.com/xiph/Icecast-libshout/issues/14
Users report random "hangs" and being unable to connect. We need a better understanding of what goes wrong on a technical level.Migrated from GitHub: https://github.com/xiph/Icecast-libshout/issues/14
Users report random "hangs" and being unable to connect. We need a better understanding of what goes wrong on a technical level.Philipp SchafftPhilipp Schafft