About Mt. Gox flaw from a security expert

[BBanzai]

Specifically, I went to school to understand theory.  It was pure, uncontaminated by "random" errors in measurement, precise to a degree that only real mathematicians can see.  Along the way, I noticed that it was disconnected from the world, it existed in pure minds as a silver blade that was perfect for fighting ghosts, should you find yourself plagued by ghosts.  Perfect for dismantling the arguments of those dimmer folk that crawl along the walls of the ivory tower, and perfect for claiming intellectual victory over those less informed.  Those with less clarity of mind.

It was also false.  Mental masturbation on a higher level.  A symptom of having the tools of math and engineering in your belt more than a sign of them.  Engineers do not quote theory, they make engines.  So I say again to the community.  Buy stuff sold for bitcoins.  Make stuff you cann sell for bitcoins.  Do not trust either the theorists or the engineers in this game.  If you happen to be one of those, be attentive to the limitations of your skill-set as well as to the advantages.

[Jaime Frontero]

well gentlemen, that was one hell of a conversation.

thank you all kindly.  as a lowly network designer, i learned a lot.  didn't cost anything, either.

whattaya youse guys think of Qubes, and their 'security by isolation' approach?

i've got no dog in the fight - but i'd really like to know what your opinions are.

[kokjo]

well gentlemen, that was one hell of a conversation.

thank you all kindly.  as a lowly network designer, i learned a lot.  didn't cost anything, either.

whattaya youse guys think of Qubes, and their 'security by isolation' approach?

i've got no dog in the fight - but i'd really like to know what your opinions are.

it will work, as long as:
a) the hypervisor is not compromised
b) the machines does not interact with each other, or share the same passwords.

[jgraham]

well gentlemen, that was one hell of a conversation.

thank you all kindly.  as a lowly network designer, i learned a lot.  didn't cost anything, either.

whattaya youse guys think of Qubes, and their 'security by isolation' approach?

i've got no dog in the fight - but i'd really like to know what your opinions are.

My $0.02.  

I only just read over this and someone correct me if I'm wrong but this appears to be using Xen to isolate (groups of) applications in their own VM on a single host.

My short answer:

This is at best a one trick pony and it's possibly the wrong approach.

Why (or my long answer):

I'm going to talk about some  "classes" of defense here (and these are terms I just made up so feel free to take some shots at them):

i) A defense which foils an attack (or some significant percentage of attacks) forcing attackers to use a completely different approach (ALSR - I'm sure everyones sick of me mentioning this)
ii) A defense which introduces a measurable and significant increase in difficulty to exploiting an existing flaw. (Password complexity rules, firewalls)
iii) A defense that removes one attack vector with known problems and replaces it with another which is less known. (Switching from IIS to Apache in an IIS shop)

I submit that i) is intrinsically superior to ii) and both are superior to iii)

VM isolation is at best a "Type II" defense, as it introduces the problem of detecting and compromising the hypervisor before compromising the machine and at worst it could be considered a Type III defense.  My assumption here is that a successful attack on the hypervisor means complete ownership of the machine.  Ergo,  we have reduced the problem for attackers from attacking application X from a very large selection of applications.   To attacking Hypervisor X for which the list is much smaller.    The upside is that - hopefully this also reduces the attack surface for the defenders.   This would normally be a good thing but it's only true if you assume the hypervisior is more secure than your other applications.

e.g. If I had a machine that had to run a webserver and Tomcat to provide a very simple web service to a very targeted application.  Removing that and replacing it with a few lines of well audited code could be considered reducing the attack surface of that machine.   However the hypervisor isn't a small piece of software and it's attack surface isn't well known.

It might be safer if I couldn't already do half the job: Detect running in a VM.   For lots of people who haven't installed the vmware tools on their host a simple check of the time with an external source will tell you that you're running on a VM.   Depending on the guest OS I've read about at least fifty different markers for VM detection.

Also it's worth noting that the point of Qubes seems to be the antithesis of what I understand to be best practice with regard to VM's these days.  Some of us think that depending on VM isolation is a bad idea.  It violates the principle of DiD.  So, like in my shop we consider it a bad idea to mix VMs with differing security privileges on the same host.  In other words we don't run the payment gateway software on a VM on the same machine we are running the Drupal VM.  Yet this seems to be the whole point of Qubes.  

This is a good presentation. http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf

More info on the VMChat teaser at the end: http://www.foolmoon.net/cgi-bin/blog/index.cgi?category=Security%20News

[Jaime Frontero]

well gentlemen, that was one hell of a conversation.

thank you all kindly.  as a lowly network designer, i learned a lot.  didn't cost anything, either.

whattaya youse guys think of Qubes, and their 'security by isolation' approach?

i've got no dog in the fight - but i'd really like to know what your opinions are.

My $0.02.  

I only just read over this and someone correct me if I'm wrong but this appears to be using Xen to isolate (groups of) applications in their own VM on a single host.

My short answer:

This is at best a one trick pony and it's possibly the wrong approach.

Why (or my long answer):

I'm going to talk about some  "classes" of defense here (and these are terms I just made up so feel free to take some shots at them):

i) A defense which foils an attack (or some significant percentage of attacks) forcing attackers to use a completely different approach (ALSR - I'm sure everyones sick of me mentioning this)
ii) A defense which introduces a measurable and significant increase in difficulty to exploiting an existing flaw. (Password complexity rules, firewalls)
iii) A defense that removes one attack vector with known problems and replaces it with another which is less known. (Switching from IIS to Apache in an IIS shop)

I submit that i) is intrinsically superior to ii) and both are superior to iii)

VM isolation is at best a "Type II" defense, as it introduces the problem of detecting and compromising the hypervisor before compromising the machine and at worst it could be considered a Type III defense.  My assumption here is that a successful attack on the hypervisor means complete ownership of the machine.  Ergo,  we have reduced the problem for attackers from attacking application X from a very large selection of applications.   To attacking Hypervisor X for which the list is much smaller.    The upside is that - hopefully this also reduces the attack surface for the defenders.   This would normally be a good thing but it's only true if you assume the hypervisior is more secure than your other applications.

e.g. If I had a machine that had to run a webserver and Tomcat to provide a very simple web service to a very targeted application.  Removing that and replacing it with a few lines of well audited code could be considered reducing the attack surface of that machine.   However the hypervisor isn't a small piece of software and it's attack surface isn't well known.

It might be safer if I couldn't already do half the job: Detect running in a VM.   For lots of people who haven't installed the vmware tools on their host a simple check of the time with an external source will tell you that you're running on a VM.   Depending on the guest OS I've read about at least fifty different markers for VM detection.

Also it's worth noting that the point of Qubes seems to be the antithesis of what I understand to be best practice with regard to VM's these days.  Some of us think that depending on VM isolation is a bad idea.  It violates the principle of DiD.  So, like in my shop we consider it a bad idea to mix VMs with differing security privileges on the same host.  In other words we don't run the payment gateway software on a VM on the same machine we are running the Drupal VM.  Yet this seems to be the whole point of Qubes.  

This is a good presentation. http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf

More info on the VMChat teaser at the end: http://www.foolmoon.net/cgi-bin/blog/index.cgi?category=Security%20News

thanks for that.

i do like the bare-metal approach, but yes - "My assumption here is that a successful attack on the hypervisor means complete ownership of the machine."

i also like that networking runs in an untrusted security ring.

i've got a play machine ready to install, and i guess i'll have to see how it goes with the newly released beta.  the isolation rule sets appear to be key.  oughtta be fun, anyway...

[BBanzai]

I'm sure this conversation should be allowed to die an ugly and painful death...but I've been away from the thread for several days and just realised that I (and others) have been accused of dismissing MuadDib's arguments out of hand.  As you might have noticed, I agree that OpenBSD has an excellent reputation and has had one for many years.  A similar argument about reputation was why I brought up VMS to begin with.  But that is not the point.  Real security lies in the administrator, not in the operating system.  Its a worldview issue more than a coding issue.  Out of the box features are great specifically because out of the box admins are morons.  By and large.