Penetration Testing mailing list archives
Re: [PEN-TEST] HP's VirtualVault
From: "Laumann, Dave" <dlaumann () SUNTZU NET>
Date: Tue, 24 Oct 2000 16:22:13 -0500
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
Current thread:
- [PEN-TEST] HP's VirtualVault Death's Apprentice (Oct 21)
- Re: [PEN-TEST] HP's VirtualVault Alfred Huger (Oct 21)
- Re: [PEN-TEST] HP's VirtualVault Death's Apprentice (Oct 24)
- <Possible follow-ups>
- Re: [PEN-TEST] HP's VirtualVault Laumann, Dave (Oct 25)
- Re: [PEN-TEST] HP's VirtualVault Jeffrey W. Thompson (Oct 25)
- Re: [PEN-TEST] HP's VirtualVault Alfred Huger (Oct 21)