Solaris 10 Containers / Zones Security Flaw

[jim allan]

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 /de
v /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 z
one 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, inc
luding 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 documenta
tion 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

[Robert Escue]

jim allan wrote:

>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 /d
ev /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 selve
s 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, in
cluding 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 ou
t 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 document
ation 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
>
>
>
>
Jim,

Did you install bash or use the supplied one with Solaris 10
(/usr/bin/bash)? Because I cannot duplicate the results you got on my
Ultra 2 using a your fork bomb in a bash shell as an unprivileged user,
see below:

This is the session I started after I ran the fork bomb for at least 15
minutes:

login as: luser
Password:
Last login: Sat Apr 2 10:26:15 2005 from 192.168.1.12
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
-bash-3.00$ id
uid=101(luser) gid=10(staff)
-bash-3.00$

This is the screen output of the session where I launched the fork bomb:

-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: xmalloc: execute_cmd.c:267: cannot allocate 32 bytes (0 bytes
allocated)
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: xmalloc: execute_cmd.c:267: cannot allocate 32 bytes (0 bytes
allocated)
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space
-bash: fork: Not enough space

This is the output of prstat -Z showing the activity of the zone zonetest:

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
10950 root 7040K 4520K cpu1 59 0 0:00:00 0.2% prstat/1
10939 root 10M 4864K sleep 59 0 0:00:00 0.0% sshd/1
1219 root 3696K 1752K sleep 59 0 0:00:00 0.0% nscd/25
10944 luser 5208K 2344K sleep 59 0 0:00:00 0.0% bash/1
5812 root 5976K 2496K sleep 59 0 0:00:00 0.0% sendmail/1
1188 root 3552K 648K sleep 59 0 0:00:00 0.0% sh/1
1138 daemon 6552K 1792K sleep 59 0 0:00:00 0.0% kcfd/3
1107 root 12M 328K sleep 59 0 0:00:04 0.0% svc.startd/13
1275 root 6016K 1568K sleep 59 0 0:00:00 0.0% syslogd/14
1214 root 4976K 8K sleep 59 0 0:00:00 0.0% cron/1
1223 root 2120K 824K sleep 59 0 0:00:00 0.0% ttymon/1
1181 root 6936K 264K sleep 59 0 0:00:01 0.0% inetd/4
1184 root 1256K 936K sleep 59 0 0:00:00 0.0% utmpd/1
1173 daemon 2936K 8K sleep 59 0 0:00:00 0.0% statd/1
1268 root 6176K 1112K sleep 59 0 0:00:00 0.0% sshd/1
ZONEID NPROC SIZE RSS MEMORY TIME CPU ZONE
2 36 193M 36M 2.4% 0:00:25 0.2% zonetest




Total: 36 processes, 106 lwps, load averages: 0.01, 1.02, 19.88

And finally the output of prstat -a showing the activity of the whole
system:

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
10951 root 7040K 4520K cpu0 59 0 0:00:00 0.1% prstat/1
1219 root 3696K 1752K sleep 59 0 0:00:00 0.0% nscd/25
5812 root 5976K 2496K sleep 59 0 0:00:00 0.0% sendmail/1
1107 root 12M 328K sleep 59 0 0:00:04 0.0% svc.startd/13
1275 root 6016K 1568K sleep 59 0 0:00:00 0.0% syslogd/14
1214 root 4976K 8K sleep 59 0 0:00:00 0.0% cron/1
1223 root 2120K 824K sleep 59 0 0:00:00 0.0% ttymon/1
1181 root 6936K 264K sleep 59 0 0:00:01 0.0% inetd/4
1188 root 3552K 648K sleep 59 0 0:00:00 0.0% sh/1
1184 root 1256K 936K sleep 59 0 0:00:00 0.0% utmpd/1
1173 daemon 2936K 8K sleep 59 0 0:00:00 0.0% statd/1
1138 daemon 6552K 1792K sleep 59 0 0:00:00 0.0% kcfd/3
1268 root 6176K 1112K sleep 59 0 0:00:00 0.0% sshd/1
1222 root 1984K 752K sleep 59 0 0:00:00 0.0% sac/1
1109 root 9128K 264K sleep 59 0 0:00:20 0.0% svc.configd/12
NPROC USERNAME SIZE RSS MEMORY TIME CPU
28 root 148M 29M 1.9% 0:00:25 0.1%
4 luser 31M 6096K 0.4% 0:00:00 0.0%
4 daemon 14M 1816K 0.1% 0:00:00 0.0%


Total: 36 processes, 105 lwps, load averages: 0.01, 0.57, 16.39

There are multiple ways of controlling resource use in Solaris 10, but
if you want to limit total processes you could use these lines in
/etc/system:

set maxuprc=(number of processes)

For more information:

http://docs.sun.com/app/docs/doc/806-7009/6jftnqsjd?a=view


Robert Escue
System Administrator

[Jonathan Katz]

Jim, et al,

I hate to sound like a shill, especially because I'm not working at
Sun, but starting with Solaris 9, Solaris ships with Sun Resource
Manager bundled with the OS. Resources can be allocated in "pools"
which can be a set number of processors, memory, etc. Rules for pools
are far more abstract than "bind this zone or process to this
processor" (see pbind(1m) for the old way of doing things.) The rules
can be more along the lines of "pool A cannot take up more than 50% of
the CPU resources on the system, but pool A has a lower priority than
pool B and can pool A give up 50% of its available CPU if pool B
requires the resources." There are a lot of knobs that can be turned.
See pooladm(1m) and poolcfg(1m) for more info. zonecfg(1m) shows how a
zone can be linked to a pool, and the zonecfg manpage references the
pooladm and poolcfg pages.

This goes back to a fundamental question of computer security; if
there is a new option (in this case zones) is to be enabled the
ramifications of enabling that option must be weighed and
investigated. Documentation needs to be read and researched and any
production deployment requires some kind of functional testing... by
running that bash "bomb" in a zone, Jim has done some great functional
testing.

Depending on the day of the week it could be considered a troll or a
good philosophical question of whether or not Sun needs to ship zones
with some kind of resource limits enabled, but at the end of the day,
one thing holds true; zones aren't created "out of the box." A user or
admin needs to manually create a zone, and just as they can create a
zone without any resource limits they can also create a .rhosts
containing "+ +"

Just my $.02.

--
-Jon
Jonathan Katz -- J. Random BOFH

On 1 Apr 2005 07:38:04 -0000, jim allan <intehnet@gmail.com> wrote:
>
>
> 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 selv
es 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, i
ncluding 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 o
ut 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 documen
tation 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
>