bugtraq - Solaris 10 Containers / Zones Security Flaw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: 1 Apr 2005 07:38:04 -0000
From: jim allan <intehnet@...il.com>
To: bugtraq@...urityfocus.com
Subject: 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