Bitcoin Forum
December 11, 2016, 12:25:43 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14]  All
  Print  
Author Topic: About Mt. Gox flaw from a security expert  (Read 32140 times)
BBanzai
Member
**
Offline Offline

Activity: 84



View Profile
July 05, 2011, 01:17:48 AM
 #261

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.
1481415943
Hero Member
*
Offline Offline

Posts: 1481415943

View Profile Personal Message (Offline)

Ignore
1481415943
Reply with quote  #2

1481415943
Report to moderator
1481415943
Hero Member
*
Offline Offline

Posts: 1481415943

View Profile Personal Message (Offline)

Ignore
1481415943
Reply with quote  #2

1481415943
Report to moderator
1481415943
Hero Member
*
Offline Offline

Posts: 1481415943

View Profile Personal Message (Offline)

Ignore
1481415943
Reply with quote  #2

1481415943
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481415943
Hero Member
*
Offline Offline

Posts: 1481415943

View Profile Personal Message (Offline)

Ignore
1481415943
Reply with quote  #2

1481415943
Report to moderator
1481415943
Hero Member
*
Offline Offline

Posts: 1481415943

View Profile Personal Message (Offline)

Ignore
1481415943
Reply with quote  #2

1481415943
Report to moderator
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126


View Profile
July 05, 2011, 08:31:46 AM
 #262

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
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
July 05, 2011, 08:48:17 AM
 #263

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.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
jgraham
Full Member
***
Offline Offline

Activity: 140


<Pretentious and poorly thought out latin phrase>


View Profile
July 05, 2011, 03:05:21 PM
 #264

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


I'm rather good with Linux.  If you're having problems with your mining rig I'll help you out remotely for 0.05.  You can also propose a flat-rate for some particular task.  PM me for details.
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126


View Profile
July 05, 2011, 04:55:31 PM
 #265

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
Member
**
Offline Offline

Activity: 84



View Profile
July 11, 2011, 05:18:36 AM
 #266

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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!