<<< Date Index >>>     <<< Thread Index >>>

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