[Icecast] [Fwd: IceCast up to v2.20 multiple vulnerabilities]

Michael Smith mlrsmith at gmail.com
Sat Mar 19 09:10:22 UTC 2005

On Sat, 19 Mar 2005 01:24:59 -0700, Stauf <stauf at freshcheese.net> wrote:
> Hash: SHA1
> Hey all,
> did you happen to see this recent post to bugtraq?  If so, I apologize.
>  I haven't been keeping up with the archives since everything has been
> running so smoothly. ;)
> - --Stauf

Nope, hadn't seen these. I guess this person didn't think contacting
the icecast developers in any way was a good idea. Which isn't very
helpful. Thanks for forwarding.

> 1) The XSL parser has some unchecked buffers (local), but they dont seem
> to be exploitable. If they are, they can be used for priviledge
> escalation, under the user that the server runs.
> <xsl:when test="<lots of chars>"></xsl:when>
> <xsl:if test="<lots of chars>"></xsl:if>
> <xsl:value-of select="<lots of chars>" />

Not sure what this is about, really. If whatever it is is exploitable,
it sounds like it requires a custom xsl file. Since the xsl files are
in the filesystem, and presumably only editable by the icecast user
anyway, I don't see that you could do anything with it.

> 2) Cause XSL parser error "Could not parse XSLT file". (Not very useful).
> GET /status.xsl> HTTP/1.0
> GET /status.xsl< HTTP/1.0
> GET /<status.xsl HTTP/1.0

The third of these is definately not a bug. The first two shouldn't be
being picked up as being xsl requests to begin with (because the url
doesn't end with ".xsl", so there's probably a bug somewhere. Possibly
the same bug as the next item...

> 3) XSL parser bypass. (Useful to steal customized XSL files, lol).
> GET /auth.xsl. HTTP/1.0
> GET /status.xsl. HTTP/1.0

Unlikely to disclose any sensitive information in practice, but
clearly a (minor) security bug that needs fixing. This _should_ just
be falling through to generic fileserving, and failing to find a file
called "auth.xsl.", and so giving a 404.


More information about the Icecast mailing list