Icecast - Sep 2018 - How to troubleshoot admin auth values in url format http://admin:password@icecast.org:1234

Hello,

I'm asking if there is a way to do extra troubleshooting for admin auth, by
adjusting a config parameter (i.e. loglevel), then looking at log files.


Sometimes I can auth properly when trying to update metadata using a url
with basic auth embedded before the server/hostname, requested from a web
browser like google chrome.

i.e.
http://admin:password at
icecast.org:1234/admin/metadata?mode=updinfo&mount=...
etc

Other times, I can't, and I can't figure out why not.


1. Does admin:password in this scenario (a web browser request) need to be
encoded to Base64, or can it be the "normal / plaintext" i.e.
"admin" ?

Reading the code on Github, in src/connection.c
static int _check_pass_http

it appears it calls a method util_base64_decode, so it appears it is trying
to decode it.

but sometimes this works from a web browser request when username:password
is typed in plaintext (not base64encoded)

does the browser automatically encode it behind the scenes before the
network tranmission?


2. is there anyway to enable a more detailed logging level which would be
able to echo the values submitted, to validate if they are being changed by
the web browser during transmission?

in same code file, I see
WARN1("Base64 decode of Authorization header \"%s\" failed",
header+6); In
which log would this appear? access or error?


Thank you.
3.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20180924/c4ccbede/attachment.html>

Good morning,

On Mon, 2018-09-24 at 23:49 -0400, Steve Wasiura wrote:
> Hello,
> 
> I'm asking if there is a way to do extra troubleshooting for admin
auth, by
> adjusting a config parameter (i.e. loglevel), then looking at log files.
Have you check the accesslog? This would be the first place to look.

> Sometimes I can auth properly when trying to update metadata using a url
> with basic auth embedded before the server/hostname, requested from a web
> browser like google chrome.
> 
> i.e.
> http://admin:password at
icecast.org:1234/admin/metadata?mode=updinfo&mount=...
> etc
> 
> Other times, I can't, and I can't figure out why not.
Note that calling this API node is only for legacy codecs like MP3 and
AAC. You should avoid using them.


Also note that this API endpoint is special. It may require you to
connect from the same source IP as the actual source you try to update.
(Details are different for different versions of Icecast.) This is due
to a flaw in those codec's design that would allow an attack on the
server without this security check.


> 1. Does admin:password in this scenario (a web browser request) need to be
> encoded to Base64, or can it be the "normal / plaintext" i.e.
"admin" ?
> 
> Reading the code on Github,
Don't. Use Our official repo at:
http://git.xiph.org/?p=icecast-server.git;a=summary
or even better:
https://gitlab.xiph.org/xiph/icecast-server/tree/master


> in src/connection.c
> static int _check_pass_http
> 
> it appears it calls a method util_base64_decode, so it appears it is trying
> to decode it.
> 
> but sometimes this works from a web browser request when username:password
> is typed in plaintext (not base64encoded)
> 
> does the browser automatically encode it behind the scenes before the
> network tranmission?
It does. No need to care about it. :)

> 2. is there anyway to enable a more detailed logging level which would be
> able to echo the values submitted, to validate if they are being changed by
> the web browser during transmission?
Not directly. Also how much Icecast logs depends on it's version.

> in same code file, I see
> WARN1("Base64 decode of Authorization header \"%s\"
failed", header+6); In
> which log would this appear? access or error?
error log.
> 
> Thank you.
> 3.
I hope that the above is of help for you. I feel like the same-ip check
is the relevant one as this could explain why it works sometimes.

With best regards,

-- 
Philipp.
 (Rah of PH2)