Solaris 10 Containers / Zones Security Flaw
all,
thought i'd share something from a bit of home research. It's a bit trivial,
and the "hole" (so to speak) is easily patched up, but it defies the claims of
Sun in regards to Solaris 10 security.
Solaris 10 contains a feature called containers, or zones, which are kind of
like a "VMware" "session" embedded inside the kernel. These seperate zones have
their own ip address (virtual interface off a physical interface, eg; bge0:1),
their own /proc /dev /etc and file system, entirely their own operating system,
and unable to affect the master, or other zones.
Sun suggest zones are good for running separate internet facing applications,
for example, a sol10 box runs a webserver in one zone, and an internal DNS on
another zone. If the internet facing web server gets compromised, and an
attacker drops them selves to root on that zone, whilst they are physically
connected to the box, they cannot go outside that zone, often, they'll have to
be wise to solaris 10 to even know they are in a zone, and it's not it's own
box.
They can compromise and wreck havoc in that zone, without any other zones, or
the master zone, from which all zones are controlled, being affected. There is
NO way to drop out of a slave zone into a master zone (yet...) unless you
logged into the master zone first. I hope that makes sense.. read suns webpage
if you wanna know more. http://www.sun.com/software/solaris/
Here's where it gets interesting. By default, there is no limit on virtual
memory or cpu time for each zone. By doing a standard bash fork bomb, I was
able to take down an entire Solaris 10 box, from within a non-master zone. All
zones were locked up, including the master zone.
It's nothing ground breaking, but I just found it interesting/poor that Sun
didn't place, by default, CPU or memory limits on zones, which are meant to be,
essentially, master of their own domain, and unable to affect other zones. One
would have to go out of their way to configure CPU limits.
See bash fork bomb below.
#!/usr/local/bin/bash
:(){ :|:& };:
ps; if you wish to patch this, either set a ulimit to the amount of virtual
memory a user can have, or explore the set up of zones, i've been told there is
a way to configure a limit to cpu time, although i haven't been able to find
any relevant documentation after a brief search.
I'm considering writing a patch using solaris 10's dtrace D language to capture
a process that is forking X amount in Y time, given some miracle that I have
some free time once in a while :)
look forward to your replies
jim allan
intehnet at g mail dot com