PDA

View Full Version : SlimServer on a visible IP -- Where do we stand on security?



Sally Shears
2005-01-04, 10:05
I have SlimServer on a box visible to the whole world...

Where do we stand on security? We see day by day of new buffer
overflows and other exploits being found in pretty mature software.

Has anyone done any serious security examination on SlimServer? What
kind of care and programming standards are evident in the code viz
security? Does anyone here know how to do this? Is anyone looking at
this that wants help?

It would be much better if we got the gremlins out ourselves so we
never see SlimServer in unpleasant headlines due to a breach.

-- Sally (very happy with Slim/Squeeze)
--
Sally Shears (a.k.a. "Molly")
SallyShears (AT) gmail (DOT) com -or- Sally (AT) Shears (DOT) org
(was sshears (AT) theWorld (DOT) com)

Jules Taplin
2005-01-04, 15:12
Hi Sally.

I'd suggest very strongly that having slimserver open to the outside
world like that isn't a desparately smart thing to do.

Slimserver has a (limited) quantity of security features built in, and
follows good practice in terms of running with least-privilege (although
I question the approaches that some people have suggested on the list
making the Windows version able to see network file shares). Equally, as
a perl program, memory allocation and the like is managed outside of our
code, so things like a good style 'C' buffer overflow aren't likely to
hand your machine to the bad guys. However... slimserver is NOT a
hardened service expected to talk to the big bad world, and if nothing
else, would be trivial to denial-of-service into the ground (a couple of
hundred 'search by song' requests per second should make pretty damned
sure it never comes back and talks to us again).

I'm not sure what your motivations for putting slimserver out in public
are, but might I suggest a little more security might be in order.
Apache reverse-proxies for the web interface could enforce some stronger
access control, and I'd recommend an SSH tunnel for allowing softsqueeze
(or potentially even an SB itself, with a bit of magic) to be able to
see the protocol ports.

In terms of a decent code audit... it's an interesting idea... but I can
see two major problems - the first is the nature of slimserver itself -
it's really not designed with strong security in mind - there are
enhancement requests for things like more granular access control, but
nobody's stepped up to the plate to work on them to my knowledge. The
second is the pace of development, particularly in the Plugins part of
the world.

With my professional hat on, I do a degree of work with our software and
hosting teams trying to make sure that they are paying attention to
security as part of their activity, and I could probably re-work some of
the material I use for that, but to be honest, there's probably better
resources out there in the world (OWASP is always worth pointing
developers at, particularly after they've just committed a vast faux-pas
*grin*).

Thinking about it - a correctly configured slimserver (at least on a
UNIX platform) should have no privilege to do more than influence it's
own datasets, and write to the playlists directory. Resource exhaustion
from writing endlessly long playlists, or forcing errors to the log file
(in /tmp - not necessarily the brightest place - on Solaris, at least,
/tmp is normally Virtual Memory, so you could theoretically starve
effective store out of the box by causing many, many log file writes),
or simply causing the slimserver process to baloon in size could all
potentially knock the machine over, but I can't currently think of a
remote exploit using it.

Attacking the slim protocols might be interesting, though. I haven't
looked at them in detail, but if they're not paranoid enough, an open
slimserver might be convinced, with specially crafted packets, to start
streaming audio to arbitrary IP addresses. Given the signalling is
small, and 44KHz PCM gets big quickly, they might make a good DoS
amplifier (sort of like the 'smurf' attacks of old).

Food for thought there though, certainly.


-- Jules


Sally Shears wrote:

>I have SlimServer on a box visible to the whole world...
>
>Where do we stand on security? We see day by day of new buffer
>overflows and other exploits being found in pretty mature software.
>
>Has anyone done any serious security examination on SlimServer? What
>kind of care and programming standards are evident in the code viz
>security? Does anyone here know how to do this? Is anyone looking at
>this that wants help?
>
>It would be much better if we got the gremlins out ourselves so we
>never see SlimServer in unpleasant headlines due to a breach.
>
> -- Sally (very happy with Slim/Squeeze)
>
>

Sally Shears
2005-01-04, 19:22
Jules, thank you very much for the thoughtful reply.

I'll add my comments below.

On Tue, 04 Jan 2005 22:12:10 +0000, Jules Taplin
<slim-discuss (AT) ourhouse (DOT) org.uk> wrote:
> I'd suggest very strongly that having slimserver open to the outside
> world like that isn't a desparately smart thing to do.

OK, got it. Thanks for the clarity.

> I'm not sure what your motivations for putting slimserver out in public
> are, but might I suggest a little more security might be in order.
> Apache reverse-proxies for the web interface could enforce some stronger
> access control, and I'd recommend an SSH tunnel for allowing softsqueeze
> (or potentially even an SB itself, with a bit of magic) to be able to
> see the protocol ports.

I'm familiar with SSH tunneling... How to do this with a SqueezeBox?
Hmm... If I put a computer at the remote site, then the two hosts run
the tunnel and the remote SqueezeBox thinks the SlimServer is local.
I like that.

Why am I interested?
- Streaming music to a remote location
- I happen to have SlimServer on a machine that is also a fileserver
I want to see from outside
- And, I'm just curious.

....snip...

> Thinking about it - a correctly configured slimserver (at least on a
> UNIX platform) should have no privilege to do more than influence it's
> own datasets, and write to the playlists directory.

Yes, I can see that now. On Mac OS X, SlimServer runs as a user, not
root. In fact, I could make this even better by installing SlimServer
in a non-admin account. Even as an Admin user on Mac OS X, it would
still require authentication to do much damage. I like that.

Can we run SlimServer on Mac OS X as a non-admin user? Giving it a
try... Yes, SlimServer can run as a non-admin user. (However, it's not
easy to move your iTunes setup from one account to another on the same
machine, so I gave up.)

> ... Resource exhaustion
> from writing endlessly long playlists, or forcing errors to the log file
> (in /tmp - not necessarily the brightest place - on Solaris, at least,
> /tmp is normally Virtual Memory, so you could theoretically starve
> effective store out of the box by causing many, many log file writes),
> or simply causing the slimserver process to baloon in size could all
> potentially knock the machine over, but I can't currently think of a
> remote exploit using it.

From this, I'm starting to think that the biggest downside is denial
of service on the machine running SlimServer. That's a risk I can
accept. I would be more worried about a
machine-taken-over-for-nasty-stuff scenario.

> Attacking the slim protocols might be interesting, though. I haven't
> looked at them in detail, but if they're not paranoid enough, an open
> slimserver might be convinced, with specially crafted packets, to start
> streaming audio to arbitrary IP addresses. Given the signalling is
> small, and 44KHz PCM gets big quickly, they might make a good DoS
> amplifier (sort of like the 'smurf' attacks of old).

You're saying that an attacker who found a bunch of slimservers could
use them to create a distributed DoS attack on some target. Yup,
that's ugly. But, the people trying to do DoS's have an easier mark in
the zillions of unprotected windows machines. Doesn't seem like too
serious a risk.

My net on all of this so far... I can all the remote stuff I want
through an SSH tunnel. I'm tempted to block at the firewall everything
from the outside world except SSH and maybe HTTP.

--
Sally Shears (a.k.a. "Molly")
SallyShears (AT) gmail (DOT) com -or- Sally (AT) Shears (DOT) org
(was sshears (AT) theWorld (DOT) com)