Icecast - May 2017 - Circumvention of authentication when using fallback mounts

Using latest icecast, let's assume the following hosting scenario.

We have 2 mountpoints which are configured with authentication callbacks:

/mount1
/mount2

Both mountpoints have configured the same fallback stream, mounted at
'/fallback'. Both have fallback-override enabled, so they both can move
listeners back from the fallback when they come online.

Suppose that both mounts are currently not mounted. Now a client is
connecting and successfully authenticating with mountpoint /mount1.
Because /mount1 is not yet available, he is moved to /fallback.

Now suppose /mount2 comes online. The client is now moved from /fallback
to /mount2, even though he has never authenticated with /mount2, but
only with /mount1. In fact, the client has no permission at all to
connect to /mount2.

In short, authentication can be circumvented if the same fallback stream
is configured for two 'authenticatable' streams.

This would not be a problem if we only used two mounts. We could simply
configure two separate fallbacks.

But suppose now that we use a wildcard to configure not just two, but N
private mounts, i.e. /mount*, so that the mount name is fully determined
by the source client. In this scenario, we cannot use a common fallback
mount any more without possible circumvention of authentication.

Latter scenario is useful when the N mounts carry private audio, and
fall back to one stream of 'fallback' music.

Is there any way to make this scenario work?

Thanks,
Michael

Good afternoon,


On Fri, 2017-05-12 at 14:37 +0200, Michael Franzl wrote:
> Using latest icecast, let's assume the following hosting scenario.
(For the records: this applies to 2.4.x as well as current 2.5.x.)

> We have 2 mountpoints which are configured with authentication callbacks:
> 
> /mount1
> /mount2
> 
> Both mountpoints have configured the same fallback stream, mounted at
> '/fallback'. Both have fallback-override enabled, so they both can
move
> listeners back from the fallback when they come online.
> 
> Suppose that both mounts are currently not mounted. Now a client is
> connecting and successfully authenticating with mountpoint /mount1.
> Because /mount1 is not yet available, he is moved to /fallback.
> 
> Now suppose /mount2 comes online. The client is now moved from /fallback
> to /mount2, even though he has never authenticated with /mount2, but
> only with /mount1. In fact, the client has no permission at all to
> connect to /mount2.
> 
> In short, authentication can be circumvented if the same fallback stream
> is configured for two 'authenticatable' streams.
> 
> This would not be a problem if we only used two mounts. We could simply
> configure two separate fallbacks.
Basically Icecast moves back the listeners without checking which mount
they came from.

> But suppose now that we use a wildcard to configure not just two, but N
> private mounts, i.e. /mount*, so that the mount name is fully determined
> by the source client. In this scenario, we cannot use a common fallback
> mount any more without possible circumvention of authentication.
> 
> Latter scenario is useful when the N mounts carry private audio, and
> fall back to one stream of 'fallback' music.
Yes. It also applies in case you have manual configuration for multiple
mount sharing the same fallback.

> Is there any way to make this scenario work?
Not as of now (beside a lot of fallbacks).

A bit of a technical sidenote:
Basically the client structure would need to keep track of which sources
the client was attached to in form of a stack. This is important as
there can be fallbacks of fallbacks (and there are valid reasons to
build something like that). A pure 'original mount' thing may result in
unexpected behavior. That being even more true if there are multiple
paths from one mount to another.


Speaking of a solution:
I think this is a very valid request for 2.5.x. I would open a ticket
for it if you don't want to do it yourself. But 2.5.x is still beta. On
the other side 2.4.x will only updated with (security or regression)
fixes. So I don't see it entering 2.4.x (unless tbr, our Project Manager
decides otherwise).

Would a update for 2.5.x help you?

If you need a backport for 2.4.x you might consider contacting me
off-list.

I hope that this mail was at least helpful by confirming the problem.


Wish you a good weekend,

with best regards,

-- 
Philipp Schafft (CEO/Gesch?ftsf?hrer) 
Telephon: +49.3535 490 17 92

L?wenfelsen UG (haftungsbeschr?nkt)     Registration number:
Bickinger Stra?e 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20170513/3a96d80f/attachment.sig>

On 05/13/2017 03:12 PM, Philipp Schafft wrote:
> Basically the client structure would need to keep track of which sources
> the client was attached to in form of a stack. This is important as
> there can be fallbacks of fallbacks (and there are valid reasons to
> build something like that). A pure 'original mount' thing may
result in
> unexpected behavior. That being even more true if there are multiple
> paths from one mount to another.
Sounds about right. Here is another unexpected but similar scenario,
which is the current behavior of Icecast:

If /music is a declared fallback stream of /voice, and a client connects
directly to /music, then, when /voice comes online, the client is be
moved to /voice, even though the client has never requested to hear voice.

I think the simplest solution would be when Icecast, for each client,
constructs a chain (a simple 1D array) of mounts he has 'fallen though',
and then, when any parent mount of this chain comes online, moves the
client up to that parent, but no further than that. If a client is moved
back up the chain, all 'lower' parts of that chain can be forgotten.

Regarding authentication in this scenario, Icecast should not
remember/cache any previous authentications. As soon as a client is
moved to *any* mount (caused by falling through or moving back), it
should do a fresh authentication request. For example, permission to
listen to a stream could have been revoked from the time a client first
connects, then falls through to a fallback, to the time when he is moved
back to a private stream.

> Speaking of a solution:
> I think this is a very valid request for 2.5.x. I would open a ticket
> for it if you don't want to do it yourself. But 2.5.x is still beta. On
> the other side 2.4.x will only updated with (security or regression)
> fixes. So I don't see it entering 2.4.x (unless tbr, our Project
Manager
> decides otherwise).
> 
> Would a update for 2.5.x help you?
This would definitely help, yes, and I would appreciate if you could
create the ticket in your system.
> I hope that this mail was at least helpful by confirming the problem.
Yes, it was.

Thank you,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20170513/e245c6c0/attachment.sig>