Icecast - Aug 2004 - URGENT: security exploit fix

Hello all.

 Anyone have any idea what it would take to separate left and right into
separate mountpoints on an icecast server? We are using Darkice on
FreeBSD. Works GREAT (still stuck running old version because the new one
bombed on compilation, but NO COMPLAINTS!)

 I'm assuming this would fall in Darkice's hands because from what I
gather it reads the pcm audio device and just passes the data to liblame.
So if it read the PCM data in stereo and then split left and right and
called two instances of liblame... ????

 Is it a possibility? It would make my life SO much easier. We are trying
to put 12 sound cards each into two systems to support 24 audio streams...
it would cut the number down to 6, or maybe even one box if there is
enough CPU power. We aren't streaming in stereo, all the sources are mono.

                                 -- Ethan

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Ethan wrote:
> Hello all.
> 
>  Anyone have any idea what it would take to separate left and right into
> separate mountpoints on an icecast server? We are using Darkice on
> FreeBSD. Works GREAT (still stuck running old version because the new one
> bombed on compilation, but NO COMPLAINTS!)
thanks
> 
>  I'm assuming this would fall in Darkice's hands because from what
I
> gather it reads the pcm audio device and just passes the data to liblame.
> So if it read the PCM data in stereo and then split left and right and
> called two instances of liblame... ????
> 
>  Is it a possibility? It would make my life SO much easier. We are trying
> to put 12 sound cards each into two systems to support 24 audio streams...
> it would cut the number down to 6, or maybe even one box if there is
> enough CPU power. We aren't streaming in stereo, all the sources are
mono.
yes, it is a possibily. I'm short of time to write the changes, though :(

<p>Akos

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

FreeBSD 4.9
Icecast 13.1
Lame 3.90, 3.93

First time, I made lame via ports and made Icecast by hand.
Core dump

Second time, I removed the port version of lame made by hand, remade
icecast. Core dump (A previous message mentioned removing the port and
making Lame by hand).

Any clues?

The problem has been mentioned a few times on the list with no real
resolve.

I have lots of other boxes running old FreeBSD, older Lame and older
Icecast.

For giggles, I grabbed an old binary from a working FreeBSD box and threw
it on the non-working one, same error.

My guess is it is with Lame or with the sound card stuff for freebsd?

My sound card is the same model that I use in 3 other hosts (14 other
streams!)

I tried moving to Lame 3.91, nothing different.

Help!

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Hi:

Firstly, there is no icecast 13.1.  I'm guessing you mean icecast 1.3.1x.
Icecast 1.x is no longer officially supported.

Having said all that, icecast is just a server - it does not use Lame and
it does not read from the soundcard.  To help you any further, it would be
best if you could load the core file into gdb or whatever the freebsd
equivalent is and let us know where it crashed.

Geoff.

<p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Ethan wrote:
>  Quick question. I'm using the old version (but looking to move to the
new
> version) of icecast. When my darkice sessions die and reconnect to the
> server the files that I have setup to be recorded get reset.
> 
>  I'm not 100% hip on the MP3 data format. Is there a header then data?
Or
> is it just data and the player syncs up with the stream?
just data, in terms of frames.

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Hello,

 Quick question. I'm using the old version (but looking to move to the new
version) of icecast. When my darkice sessions die and reconnect to the
server the files that I have setup to be recorded get reset.

 I'm not 100% hip on the MP3 data format. Is there a header then data? Or
is it just data and the player syncs up with the stream?

 Would it be possible to change the code so that if a file exists it
appends, and doesn't rewrite from 0? Or would this break the structure of
the file and cause player error?

 I'm recording 10 feeds in 24 hour segments, and sometimes the encoders
puke out. My script on the encoders restarts them, but then the archive
sets go to zero.

 Just curious, I would imagine it would be easy to change the fopen call
or whatever in the code to append if exists but I don't want to break the
file.

 I'm planning to run the 24 hour blocks of data thru another program that
breaks it down into 1 hour chunks.

 100 gigs of data a month!

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

To all users:

The recently exploits announced at bugtraq can be fixed by the following
patch.  This patch should fix a few other potential holes as well, and I
will post a followup patch soon that is even more thorough.

Note: this exploit would give the attacker priviledges of the user
running icecast.  If you are running icecast as a normal user account or
as root, this would be a good time to run it as nobody or some other
unpriveledged account.

Anyone running icecast as root better upgrade fast and do a search for
rootkits or other odd behaviors on their systems.

Regards,
jack.

----- Forwarded message from Jack Moffitt <jack@shredder.sneakyninja.com>
-----

Date: Wed, 10 Apr 2002 14:36:27 -0700 (PDT)
From: jack@shredder.sneakyninja.com (Jack Moffitt)
To: cvs@icecast.org
Subject: cvs commit: icecast/src avl_functions.c source.c
X-Spam-Status: No, hits=-3.2 required=10.0 tests=UNIFIED_PATCH,NO_MX_FOR_FROM
version=2.11

jack        02/04/10 14:36:27

  Modified:    src      avl_functions.c source.c
  Log:
  Fix security exploit (icx.c) that exploited a buffer overflow in the alias
  logic.

Revision  Changes    Path
1.9       +4 -4      icecast/src/avl_functions.c

Index: avl_functions.c
==================================================================RCS file:
/cvsroot/icecast/src/avl_functions.c,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- avl_functions.c	26 May 2000 15:47:55 -0000	1.8
+++ avl_functions.c	10 Apr 2002 21:36:27 -0000	1.9
@@ -156,8 +156,8 @@
                 write_log (LOG_DEFAULT, "WARNING: compare_relays() called
with NULL pointers!");
         }
 
-	sprintf (cfirst, "%s:%d%s", r1->req.host, r1->req.port,
r1->req.path);
-	sprintf (csecond, "%s:%d%s", r2->req.host, r2->req.port,
r2->req.path);
+	snprintf (cfirst, BUFSIZE, "%s:%d%s", r1->req.host,
r1->req.port, r1->req.path);
+	snprintf (csecond, BUFSIZE, "%s:%d%s", r2->req.host,
r2->req.port, r2->req.path);
         return ice_strcmp (cfirst, csecond);
 }
 
@@ -188,8 +188,8 @@
                 return -1;
         }
         
-	sprintf (full, "%s:%d%s", a1->name->host,
a1->name->port, a1->name->path);
-	sprintf (full2, "%s:%d%s", a2->name->host,
a2->name->port, a2->name->path);
+	snprintf (full, BUFSIZE, "%s:%d%s", a1->name->host,
a1->name->port, a1->name->path);
+	snprintf (full2, BUFSIZE, "%s:%d%s", a2->name->host,
a2->name->port, a2->name->path);
 
         return ice_strcmp (full, full2);
 }

<p><p>1.35      +1 -1      icecast/src/source.c

Index: source.c
==================================================================RCS file:
/cvsroot/icecast/src/source.c,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- source.c	7 Aug 2001 19:16:14 -0000	1.34
+++ source.c	10 Apr 2002 21:36:27 -0000	1.35
@@ -608,7 +608,7 @@
 
         xa_debug (1, "DEBUG: Search local mount points");
 
-	sprintf(pathbuf, "%s:%d%s", req->host[0] ? req->host :
"localhost", req->port, req->path);
+	snprintf(pathbuf, BUFSIZE, "%s:%d%s", req->host[0] ? req->host
: "localhost", req->port, req->path);
 
         while ((con = avl_traverse(info.sources, &trav)) != NULL) 
         {

<p><p><p>----- End forwarded message -----

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.