SHOUTcast remote format string vulnerability
 

Hi,

The following was posted to the Bugtraq security mailing list early this morning:

Product: SHOUTcast v1.9.4 (and older?)
Vendor: http://www.shoutcast.com
Vuln: Remote format string
BugFinder: Tomasz Trojanowski (onestep)
Author: Damian Put <pucik@cc-team.org> www.CC-Team.org
Date: Dec 23, 2004


1. BACKGROUND

"SHOUTcast is Nullsoft's Free Winamp-based distributed streaming audio
system. Thousands of broadcasters around the world are waiting for you to
tune in and listen"


2. DESCRIPTION

Remote exploitation of a format string vulnerability could allow execution
of arbitrary code.

A part of request, which was sent by attacker to server, would be included
in second arg of sprintf() function (0x0804adc3 in linux binary). It is
obviously not good from a security viewpoint. We can crash SHOUTcast in a
very easy way, using following request:

http://host:8000/content/%n.mp3

Or reach remote shell thanks to attached exploit`s code.
---------------------------------

Sure enough, the attached code gives you a remote shell of the user that ran the shoutcast process.

Do the authors know of this?
when will this be fixed?
IMHO this is very high priority.

Could a mod please delete this thread? Seriously this is not something that should be advertised right now. Peep the other thread.

to be honest work a discussion here.

I have tried a few things and it looks like it comes down to if you have the content dir configured.

If you dont it doesnt not appear to be a problem, if you do, more of an issue, and even then it is a perhaps.

BW

DJ Amps, trying to cover up that there is a vulernability doesn't make it go away :) Making it more public makes the people calling the shots work faster to fix problems, although I dunno if anyone is working on shoutcast anymore hah

nail on the head their germ.

it is a shame, but it looks like Icecast is the way to go ( if you want to keep using open source ).

I suspect there will not be an update and if there is it will be several months away. There is a workaround, so the priority can be reduce, however it would be good to get a comment from the current developers ( i know they do not really do it, but there must be someone charged with ownership over at AOL), as it does kind of look bad on them.

BW

No SHIT, which is why I proposed not blatently advertising how to crash the DNAS to the general public until service providers and the rest of us had a chance to figure out patch.

This thread is not constructive.

To late now, forget it.

Simple protection from this exploit.

IP access restriction for SSH / Telnet.

How would that fix it?

well, if one aspect of the exploit is to gain access to your shell, if linux has explicit allow/deny permissions in the hosts file for SSH, then when they try to gain access to it, SSH will say Access Denied and close the window, or it will not even appear period.

Now as for crashing the DNAS, im not sure on yet... im tinkering with that atm.

i think you'll find that SSH is not invoked at all , so permissions on SSH dont help at all.

BW

I read on the exploit code that i found that it tries to telnet into the box...

From reading to that,the only way for an attacker to get remote shell, is to invoke SSH (as i read in the code)

But that won't protect from it crashing the DNAS, im looking into a way to stop that, ghetto style.

well if you can ... share :D

I run two NSVs and 3 shoutcasts ... would be brill :D

I suspect you could potentially block large requests with iptables or something similar ... but perhaps not very easy to do.

BW

okies ... iptables can do it ...

limit the size of the packet inbound , so only let in say anything upto 100 bytes ( figure out the exact length later )

make it an inbound rule and do

-d <ip of server> -p tcp -m length --length 0:200

shoud allow packets of 0:200 size in length in ... since the exploit does overloading should help people ..

comments please :D

BW

Not bad, the only issue is if you run a web server on the same box and permit uploading :-/

okies

-p tcp -m length --length 0:200 --dport 90

will only do the port you specify .. so port 90 above :D

BW

Found it much easier to rename the content folder. Neither exploit will work if they can't execute the crash and if the content folder is named something other than the obvious default they cannot crash the server - they just get an Invalud Resource error and your server is uneffected.

Worked quick and simple. Note however that the standard Linux distro requires a hex editor as it appears the contentdir is hard coded.

true, but i notice quite a few odd things in my log about large packets .. so I am going to add it to mine anyway :D

BW

That iptables rule might stop the bindshell exploit but not stop anyone from crashing the server. Best would be to impliment both tweaks.

Note that iptables rules will add additional CPU overhead on busy machines.

I found changing ContentDir in the configuration file does NOT stop the exploit (on linux), it still segfaults and binds root shell - perhaps this does need to be hard coded..

The packet size limiting is good, but couldnt you bypass that with packet fragmentation?

The regular Linux distro definately does. I worked with a provider I use last night and changing it in the config did not make any difference so he used a hex editor and found it hard coded in the executable, changed it and the server did not crash using the exploit.

It also appears this effects the Solaris version - the only server I had which I could not contact the admins and appears to have been taken out sometime during the day Christmas Eve.

Will this affect me if the "ContentDir" line is commented out in the config ?

It´s like this in my config:

; ContentDir=./content

Well crap. Do you know what lines he had modified to prevent the exploit?

i'll second that ... hex editing does appear to fix it ... i have had one of my servers die every 3 hours ...

just hex edited it ... see whats happens ..

and I had content dir set to something random etc ...

:(
BW

The windows version is also. In our log:

<12/26/04@03:38:02> [file: 82.49.47.54] ./content/AA<I=I>I?I1ÀPPfÇD$XÆ$‰æ°Í€…Àt1À1Û°
Í€Pj
j‰á1Û°f³
Í€‰ÅjVP‰á°f³Í€j
U‰á1À1Û°f³Í€1ÀPPU‰á°f³Í€‰Å1À‰ë1É°?Í€A€ù|ö1ÀPh//shh/bin‰ãPS‰á™°
Í€.mp3
<12/26/04@03:38:02> [dest: 82.49.47.54] Invalid resource request(/content/AA<I=I>I?I1ÀPPfÇD$XÆ$‰æ°Í€…Àt1À1Û°
Í€Pj
j‰á1Û°f³
Í€‰ÅjVP‰á°f³Í€j
U‰á1À1Û°f³Í€1ÀPPU‰á°f³Í€‰Å1À‰ë1É°?Í€A€ù|ö1ÀPh//shh/bin‰ãPS‰á™°
Í€.mp3)


It doesn't kill the actual process, but shoutcast doesn't respond anymore.

Windows :D

Apply the fix, change your content directories in the config ;)

this ip are hacked, blacklist theym

82.49.47.54
62.163.178.165

Same problem. Linux Fedora3

<12/25/04@21:31:31> [file: 62.163.178.165] ./content/AA<I=I>I?I1ÀPPfÇD$XÆ$‰æ°Í€…Àt1À1Û°
Í€Pj
j‰á1Û°f³
Í€‰ÅjVP‰á°f³Í€j
U‰á1À1Û°f³Í€1ÀPPU‰á°f³Í€‰Å1À‰ë1É°?Í€A€ù|ö1ÀPh//shh/bin‰ãPS‰á™°
Í€.mp3
<12/25/04@21:31:31> [dest: 62.163.178.165] Invalid resource request(/content/AA<I=I>I?I1ÀPPfÇD$XÆ$‰æ°Í€…Àt1À1Û°
Í€Pj
j‰á1Û°f³
Í€‰ÅjVP‰á°f³Í€j
U‰á1À1Û°f³Í€1ÀPPU‰á°f³Í€‰Å1À‰ë1É°?Í€A€ù|ö1ÀPh//shh/bin‰ãPS‰á™°
Í€.mp3)

Same problem, same answer.

Doesn't work, is there another vulnerability?

We need a quick update of Shoutcast 1.9.4 to 1.9.5 ? for Christmas :(

The regular linux version needs to be hex edited because the content directory is hard coded. The FreeBSD version can be modified in the .ini file. The Solaris version is also obviously effected as does it seem the Windows one is as well but I have not run across fixes for those if the regular modification of the ContentDir directive can be changed in the conf/ini files.

Note that inside word is someone is trying to get someone with access to the source code to see if a change can be made. Hopefully something clear after the holidays?

Does this really works ?
Whats the iptables command to add this rules ?

Does 1.7 or older versions are vulnerable to this hack ?

The content directory is also hard coded in the FBSD binary. Changing it it in the sc_serv.conf file did not stop this from seg faulting and doing a core dump when I hit it with the generic slackware 9.1 exploit source:

[@are test]$ ./sc_serv
*******************************************************************************
** SHOUTcast Distributed Network Audio Server
** Copyright (C) 1998-2004 Nullsoft, Inc. All Rights Reserved.
** Use "sc_serv filename.ini" to specify an ini file.
*******************************************************************************
Segmentation fault (core dumped)
[@are test]$ grep blah sc_serv.conf
ContentDir=./blah/scpromo.mp3
[@are test]$ gdb sc_serv sc_serv.core
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
(no debugging symbols found)...
Core was generated by `sc_serv'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libc_r.so.4...(no debugging symbols found)...
done.
Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...
done.
#0 0x28107b42 in vfprintf () from /usr/lib/libc_r.so.4
(gdb) quit


A hexed copy of the binary with a changed content directory does not crash.

For Windows you should be able to rename the content directory and change it in sc_serv.ini as I could not find it hard coded in the gui exe but I have yet to test this.

I hadn't tried the slackware exploit - I was under the assumption it worked off the original exploit using the /content/%n exploit originally mentioned. After changing the .conf file I tried the original exploit and it did nothing but return an Invalid Resource error since the directory had changed.

But out of safety after reading this I used a hex editor and renamed all references to the /content directory within the file. Testing it now to see if the edited version flakes out for any reason.

it does work ... but you have to make sure you apply it only to the portbase, not portbase+1 , otherwise no one with able to source their stream to your shoutcast

something like

iptables -A INPUT -d <ip of server> -p tcp -m length --length 0:50 --dport 8000

should solve it for port 8000

i also hacked the binary ... much more ... erm ... solid ;)

One comment to all. Due to the nature of the requirement to hack the binary, I assume now the user agreement has to go out of the window ?

BW

can you explain how to hexedit the file ? what soft do you need in linux for that ?

vi (or vim if you have certain linux distribs) works quite well i found ( although you have to be careful )

also, if you do not know what you are changing , be very careful ... other wise you'll find the result ... doesnt work ...

BW

I used xvi32 for Windows - worked pretty well. Just did a search for instances of /content and changed it to something else and renamed my directories. Tested it since last night and the server is stable as a rock.

I'll agree though, if you don't know how to do it you're better off having someone else do it for you. I would think this is some kind of violation of the user agreement but with the absence of another remedy there is little choice in this matter until Nullsoft releases an official patch or repair for this problem.

Interesting note - V1.9.2 (Linux at least) is immune to the %n attack.

I would recommend people who aren't comfortable hex editing switch to this version since it's definately more secure.

The only known hack for 1.9.2 requires a password at least.