Solaris 10 Containers / Zones Security Flaw

[jim allan <intehnet () gmail com>]

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