Re: [PEN-TEST] HP's VirtualVault

["Laumann, Dave" <dlaumann () SUNTZU NET>]

first, a couple of things (which you may know, but others may not) about b1
*evaluated*/trusted/multi-level network operating systems. a feature these
systems have in common is mandatory access control (mac) which is based on a
sensitivity label that is used to compare the label the user is running at
to the object the user is attempting to access. the mandatory implies the
label "checks" automatically happen, and labels cannot be changed by
non-privileged users (they are sticky across copies, etc), which is quite
different than the familiar discretionary access control (dac). mac is used
in conjunction with not in place of dac in multi-level os'.

virtual vault
a specific version of virtual vault os (vvos) is based off of a specific
version of hp-ux. so if the vvos version number is 11.04 vvos is based off
of hp-ux 11.0 the minor number 4 is the arbitrary indicator that the os is
vvos. i would expect subsequent versions of vvos to have that same minor
number appended to them. immediately you might think of looking into
problems that exist in the corresponding version of hp-ux or prior. however,
remember that vvos uses security labels, privileges, and authorizations.

security labels
there are four predefined security labels in vvos: system low, system
inside, system outside, and system high. these can be modified to anything
you like. e.g. the gov't uses top secret, secret, confidential, and
unclassified. labels are ranked from high to low. security labels govern the
access a process with a specific label has over an object with a specific
label. the types of access are: no access, read, write, read and write.
security labels are ranked from high to low. the rules governing access are:
higher label process can access a lower label object as read only, same
label process can access same label object as read and write, otherwise no
access. privilege provides a mechanism to change these constraints.

a rough diagram of vvos (fixed font):
+----------------+----------------+
| system high                     |
|                                 |
+----------------+----------------+
| system         | system         |
| outside        | inside         |
|                |                |
| nic inter      |      nic intra |
+----------------+----------------+
| system low                      |
|                                 |
+----------------+----------------+

the diagram implies:
system high can only read from system low, system inside, and system
outside;
system inside can only read from system low;
system outside can only read from system low;
writing is only permitted from and to the same label;
system inside cannot read or write to system outside and vice versa;

obviously most critical information will be stored at system low since a
higher process cannot write down to it but can read from it.

more importantly how does the internet/outside nic talk (write to and read
from) the intranet/inside nic? this is accomplished through 4 trusted
bridges and privilege: trusted gateway, cross boundary ipc, trusted gateway
proxy, and the java servlet proxy.

privilege
privileges in vvos help deal with the nasty problem of userid 0. there are
*no* checks for userid = 0, and therefore no notion of the traditional root
user. yes, you may have a user named root with all privileges but that would
be silly. there are some 40 plus privileges in vvos. essentially the power
of the root account/system calls has been segregated into 40-50 discrete
privileges. to use a silly analogy, privilege is like a key to a door. if
you have the key and access to the door. you can open the door. similarly
the key will not open any other door.

authorization
authorization is what allows a process that recognizes the authorization to
elevate privilege to perform actions. authorizations are worthless in and of
themselves. they relay on a trusted program which in turn has privilege to
use the corresponding authorization. to further extend the silly analogy,
authorization is like a badge. if the badge is recognized it could be used
to have someone with privilege (the key), say the night watchperson, open
the door on your behalf. similarly if the badge is not recognized you are
hopefully out of luck.

how then do you crack a trusted system? misconfigurations, and punch through
attacks. you will probably find that trusted systems have a higher
complexity involved in setup and integration. the potential for
misconfigurations exists. i can easily envision someone giving an object way
too much privilege because the application wouldn't work or wasn't privilege
aware. this may be your best bet into the system but the work is not over
once your in. you will need privilege to do anything of use, remember there
is no magic userid 0. if vv is used beyond the way it is intended, that is
if the application the os is trying to protect does not reside on vv then
most attacks against the target should still work. for instance buffer
overruns against an iis web server being protected by a vv should still
work. obviously, your mileage will vary, and don't expect the same results
if the application actually runs on vv.

mythrandir (of argus) gave a talk about this very topic at blackhat and
defcon.
the presentation is available online for blackhat at
http://www.blackhat.com/html/bh-usa-00/bh-usa-00-speakers.html, search for
argus. i don't have the defcon presentation...

--
Dave Laumann - CTO
Sun Tzu Security, Ltd
+1.414.289.0966x104

"If two always agree, one of them is unnecessary" -anonymous

> -----Original Message-----
> From: Death's Apprentice [mailto:mort666_i () YAHOO COM]
> Sent: Saturday, October 21, 2000 4:27 AM
> To: PEN-TEST () SECURITYFOCUS COM
> Subject: HP's VirtualVault
>
>
> I've been performing some testing on some servers that are
> running the HP
> VirtualVault version of
> HP-UX so far nothing interesting has come up, has anyone here
> seen or know
> of any holes within this platform?  I've tried most of the
> standard Unix and
> HP-UX things.  Or is there anyone who is activitly looking at
> the security
> of the platform?
>
> Thanks..
>
> Mort...
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com