Re: Virtual machine 'escape'
On Tuesday, 11/04/2008 at 09:43 EST, A. Harry Williams [EMAIL PROTECTED] wrote: My understanding is that it was also a measure of the processes in place by the vendor to build and maintain a secure environment. The higher the level, the more processes that must be documented and in place. It's more of a validation that what the vendor claims to have, and that they can back it up. Is that faulty understanding? I've thought about it as How serious is the vendor about security? Maintaining and building a secure environment are required at relatively low EALs, but each EAL does introduce more rigorous design, development, testing, and delivery processes. Your how serious? comment is well said. The fees and the PYs can easily run you $1M for an evaluation of an operating system. And this assumes you don't have to spend a bunch of money adding function to meet the standard! Alan Altmark z/VM Development IBM Endicott
Virtual machine 'escape'
It seems our colleagues doing virtualization on Intel have another possible security concern to worry about now. -- *Virtual machine escape no vacation* http://go.techtarget.com/r/4912983/567145 Brien M. Posey, Contributor Without a doubt, the hottest trend in IT today is data center consolidation through virtualization. Although virtualization can help an organization lower its operating costs significantly, and often makes information systems management easier, there are some underlying security concerns that need to be addressed. By far the biggest concern related to virtual machine security is the threat of a virtual machine escape. A virtual machine escape is a theoretical type of attack in which an attacker uses a vulnerability within a virtual machine to take control of either the underlying host operating system, or the hypervisor itself. Upon doing so, the attacker could potentially gain control of the other virtual machines hosted on the server. Why is it such a threat? It's the fear of the unknown, that eventually someone will be able to do it. READ FULL STORY http://go.techtarget.com/r/4912984/567145 DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: Virtual machine 'escape'
It seems our colleagues doing virtualization on Intel have another possible security concern to worry about now. By far the biggest concern related to virtual machine security is the threat of a virtual machine escape. A virtual machine escape is a theoretical type of attack in which an attacker uses a vulnerability within a virtual machine to take control of either the underlying host operating system, or the hypervisor itself. Upon doing so, the attacker could potentially gain control of the other virtual machines hosted on the server. Why is it such a threat? It's the fear of the unknown, that eventually someone will be able to do it. Not just possible; proven. It's been done on an Intel Pacifica chipset, and there was an excellent paper in IEEE Transactions on Computer Systems on how it was done.
Re: Virtual machine 'escape'
On Tue, 4 Nov 2008, David Boyes wrote: Not just possible; proven. It's been done on an Intel Pacifica chipset, and there was an excellent paper in IEEE Transactions on Computer Systems on how it was done. And how much are you willing to bet that *somewhere* there is a manager who will assume that z/VM has the same problem and will thereby argue against the mainframe? After virtualization is virtualization, correct? And the minor differences between System z and Intel shouldn't make any difference, right? Yes, I'm very cynical. Especially since our new owners in NYC have concluded, as has past management, that the z is simply too expensive and is, once again, looking a converting from z to something else. This time, the something else is an iSeries. Helped along, of course, by our friendly, helpful iSeries sales 'droid. sheesh -- Q: What do theoretical physicists drink beer from? A: Ein Stein. Maranatha! John McKown
Re: Virtual machine 'escape'
What effect would this same hack have on the intended target if the x86 system being targeted was running as a guest under z/VM? Wouldn't the ill effects be reduced by the wall between virtual guests inherent with z/VM? On 11/4/08 11:42 AM, David Boyes [EMAIL PROTECTED] wrote: It seems our colleagues doing virtualization on Intel have another possible security concern to worry about now. By far the biggest concern related to virtual machine security is the threat of a virtual machine escape. A virtual machine escape is a theoretical type of attack in which an attacker uses a vulnerability within a virtual machine to take control of either the underlying host operating system, or the hypervisor itself. Upon doing so, the attacker could potentially gain control of the other virtual machines hosted on the server. Why is it such a threat? It's the fear of the unknown, that eventually someone will be able to do it. Not just possible; proven. It's been done on an Intel Pacifica chipset, and there was an excellent paper in IEEE Transactions on Computer Systems on how it was done. --. .- .-. -.-- Gary Dennis Mantissa Corporation 1121 Edenton Street Birmingham, Alabama 35242-9257 p: 205.968-3942 m: 205.218-3937 f: 205.968.3932 [EMAIL PROTECTED] http://www.mantissa.com http://www.idovos.com
Re: Virtual machine 'escape'
Successful escapes from the confines of the architecture are, historically, few and far between. For a non-privileged user who is using (or abusing) z/VM on a modern System z platform to accomplish such ends would be an extraordinary feat. I say extraordinary feat only because I'm inherently suspicious of words like impossible. Interesting historical reading on the topic can be found here: *http://tinyurl.com/58jhlt* (User-hostile original URL is http://domino.watson.ibm.com/tchjr/journalindex.nsf/3d119440d938c88b85256547004c899a/2c913e6fe13f1e5285256bfa00685acf?OpenDocument) The article is Penetrating an operating system: a study of VM/370 integrity, by C. R. Attanasio, P. W. Markstein, and R. J. Phillips, from IBM Systems Journal Vol 15, Number 1, Page 102 (from way back in 1976). -dan. Gary M. Dennis wrote: What effect would this same hack have on the intended target if the x86 system being targeted was running as a guest under z/VM? Wouldn't the ill effects be reduced by the wall between virtual guests inherent with z/VM? On 11/4/08 11:42 AM, David Boyes [EMAIL PROTECTED] wrote: It seems our colleagues doing virtualization on Intel have another possible security concern to worry about now. By far the biggest concern related to virtual machine security is the threat of a virtual machine escape. A virtual machine escape is a theoretical type of attack in which an attacker uses a vulnerability within a virtual machine to take control of either the underlying host operating system, or the hypervisor itself. Upon doing so, the attacker could potentially gain control of the other virtual machines hosted on the server. Why is it such a threat? It's the fear of the unknown, that eventually someone will be able to do it. Not just possible; proven. It's been done on an Intel Pacifica chipset, and there was an excellent paper in IEEE Transactions on Computer Systems on how it was done. --. .- .-. -.-- Gary Dennis Mantissa Corporation 1121 Edenton Street Birmingham, Alabama 35242-9257 p: 205.968-3942 m: 205.218-3937 f: 205.968.3932 [EMAIL PROTECTED] http://www.mantissa.com http://www.idovos.com
Re: Virtual machine 'escape'
What effect would this same hack have on the intended target if the x86 system being targeted was running as a guest under z/VM? Wouldn't the ill effects be reduced by the wall between virtual guests inherent with z/VM? The x86 hypervisors have a wall between guests too. The first published exploits of which I'm aware are over a year old now. The attack described above would have to be tailored to the x86-on-zVM environment, but the point is that a hypervisor is a software system and just as prone to implementation errors and design flaws as any other software system. VM's advantages would appear to be: 1. Many years of refinement. 2. Less knowledge of its internals in the broad public. 3. Typically more formally engineered security and operating environments The first is weakened by the fact that the product undergoes development which can introduce new bugs. The second is prone to an attack by a moderately well funded opponent who decides that something worth stealing is held inside such a system. Organized crime, e.g. in Russia, has already demonstrated a willingness and capability to organize fairly sophisticated technical attacks where there's enough incentive. The third may be the best hope, but it is prone to the principle that the white hats have to get it right every time, whereas an opponent only has to get lucky once. De
Re: Virtual machine 'escape'
On Tue, 4 Nov 2008 13:23:40 -0500 Dennis Boone said: What effect would this same hack have on the intended target if the x86 system being targeted was running as a guest under z/VM? Wouldn't the ill effects be reduced by the wall between virtual guests inherent with z/VM? The x86 hypervisors have a wall between guests too. The first published exploits of which I'm aware are over a year old now. The attack described above would have to be tailored to the x86-on-zVM environment, but the point is that a hypervisor is a software system and just as prone to implementation errors and design flaws as any other software system. VM's advantages would appear to be: 1. Many years of refinement. 2. Less knowledge of its internals in the broad public. 3. Typically more formally engineered security and operating environments There is a 4th very important that I'm sure Alan will chime in with, EAL, Evaluation Assurance Level. http://www.commoncriteriaportal.org/products_OS.html#OS gives the certified list. VMWare: Name VMware ESX Server 2.5.0 VirtualCenter 1.2.0 Manufacturer Assurance level Certification date VMware EAL2 27-MAR-06 IBM z/VM Version 5 Release 3 Manufacturer Assurance level Certification date IBM Deutschland Entwicklung GmbH EAL4+ 28-JUL-08 EAL4+ is new. Last I looked, z/VM 5.2 was EAL3+ I believe, when I looked back in mid July. These are industry standards that you can show your management. /ahw
Re: Virtual machine 'escape'
Dennis Boone wrote: VM's advantages would appear to be: 1. Many years of refinement. Especially a convergence of the processor architecture with the software ideal. 2. Less knowledge of its internals in the broad public. This is a weakness, not a strength. It's like staying healthy by not hearing bad news from doctors. 3. Typically more formally engineered security and operating environments Better procedures. The weakness of VMWare on Intel is that it is young and the processor hasn't been remade all the way to support this yet. The VMWare idea is sound, and will endure. But when they are ready to build real enterprise class machines to run scores of OS instances virtualized on Intel 24 x 7 lights out for years at a time, such Intel boxes will look and cost very much like mainframes. -- Jack J. Woehr# Self-delusion is http://www.well.com/~jax # half the battle! http://www.softwoehr.com # - Zippy the Pinhead
Re: Virtual machine 'escape'
Not just possible; proven. It's been done on an Intel Pacifica chipset, and there was an excellent paper in IEEE Transactions on Computer Systems on how it was done. Sorry, remembered the journal wrong. Was in the Black Hat USA 2007 proceedings. My technical article slushpile is getting too large to index properly. http://www.invisiblethings.org/papers.html has the paper online, along with some other interesting things related to Intel virtualization that are worth reading. The exploit code is available from http://bluepillproject.org.
Re: Virtual machine 'escape'
What effect would this same hack have on the intended target if the x86 system being targeted was running as a guest under z/VM? Wouldn't the ill effects be reduced by the wall between virtual guests inherent with z/VM? It would be unlikely to be effective, IMHO, because it would need to be two level; at the Intel emulation layer and at the z/VM layer, and in a properly secured z/VM system with virtual machines running as class G machines, it'd be really, really hard to compromise CP without doing something very invasive via another vector (eg, compromising a privileged id with access to real storage). There's also an awful lot of hardware isolation that isn't present in the Intel space that you'd have to bypass to get into somebody else's address space. If you were smart about using the multiple address space capability of the Z processor (as CP does), then you'd also have hardware protection working for you as well, and that would take some doing to get around. Not impossible, but darn hard. -- db
Re: Virtual machine 'escape'
On Tuesday, 11/04/2008 at 02:20 EST, A. Harry Williams [EMAIL PROTECTED] wrote: There is a 4th very important that I'm sure Alan will chime in with, EAL, Evaluation Assurance Level. - z/VM 5.3 is EAL 4+ using protection profiles CAPP and LSPP. - z/OS 1.9 is EAL 4+ using protection profiles CAPP and LSPP. - RHEL 5 is EAL 4+ using protection profiles CAPP and LSPP - SLES 10 is EAL 4+ using protection profile CAPP - VMware ESX Server 3.0.2 with VirtualCenter 2.0.2 is EAL4+ with no protection profile - System z LPAR is EAL 5 with no protection profile CAPP covers, among other things, authentication, discretionary access control (authorization), and audit. LSPP expands on CAPP by adding labeled security which is a type of mandatory access control wherein the system can override the wishes of a resource owner (or admin) based on roles. These allow a simple apples-to-apples comparison of functionality. Without a standard protection profile, such as for VMware and LPAR, you must carefully read the Security Target, a document that enumerates the vendor's claims. Don't be deceived by the EAL number. It is a measure of the amount of evidence (assurance) that the vendor has provided to the evaluator to support the claims in the Security Target. It also measures the amount of effort expended by the evaluator to assess the evidence. A higher evaluation assurance level (EAL) does NOT mean it is more secure. And the plus at the end indicates that there is a mechanism to report, track, fix, and deliver fixes to the security-relevant parts of the system, a.k.a. flaw remediation. Alan Altmark z/VM Development IBM Endicott
Re: Virtual machine 'escape'
On Tue, 4 Nov 2008 16:15:52 -0500 Alan Altmark said: Don't be deceived by the EAL number. It is a measure of the amount of evidence (assurance) that the vendor has provided to the evaluator to support the claims in the Security Target. It also measures the amount of effort expended by the evaluator to assess the evidence. A higher evaluation assurance level (EAL) does NOT mean it is more secure. My understanding is that it was also a measure of the processes in place by the vendor to build and maintain a secure environment. The higher the level, the more processes that must be documented and in place. It's more of a validation that what the vendor claims to have, and that they can back it up. Is that faulty understanding? I've thought about it as How serious is the vendor about security? And the plus at the end indicates that there is a mechanism to report, track, fix, and deliver fixes to the security-relevant parts of the system, a.k.a. flaw remediation. Alan Altmark z/VM Development IBM Endicott /ahw
