Silk Road forums
Discussion => Security => Topic started by: ReUps on January 11, 2012, 01:45 am
-
Please forgive this uber noob question, but what is the point in setting up a Virtual Machine, they can't make your connection any more secure/anonymous can they?
My understanding was they gave you the ability to wipe your machine (but keep all progs) in like 2 minutes, am I missing something?
I mean I guess you could wipe your machine after closing TOR each time, so if any fucker has gotten some virus to you while you were online... is that it?
Please someone bring me up to speed here, thanks! ;D
-
with computers becoming so cheap, you can get yourself old notebook, boot it from pen drive with hardened Linux with preconfigured TOR and there is no need in VM. all your system on pendrive and your computer clean all the time, most important!!. even if you will create virtual encrypted disk and install VM like VMware on it, you will be in dangerous illusion that all you VM safe on encrypted disk, no it is not. too good to be true less to say.
-
From the end-user perspective, VMs are convenient. Install all the stuff you want on it, take a backup/snapshot before you start actually doing any work with it, and then it doesn't really matter if your VM gets malware on it. Just go back to your snapshot - it's like having a fresh install available any time you want it.
Are they more secure/anonymous? Depends on how you use them. A VM on a USB key is a lot more secure than a VM on your hard drive.
-
ReUps, don't listen to people like Tranzshipper. Anybody who says that isolating Tor under its own hypervisor, then network facing applications under a different hypervisor isn't helpful has no idea what the fuck they're talking about. zomgwtfbbq's post is 100% truth though, especially about snapshots, which many people ignore. The vbox.me flavor of VirtualBox is a godsend btw. *g*
This is a recent thread about the same subject -- http://dkn255hz262ypmii.onion/index.php?topic=7998 -- and is full of pertinent information about your question.
-
....the point of vm's is to be able to run a virtual guest (windows, Linux, mac etc.), fits into memory, easily deleted, erased.....without affecting your host.
-
....the point of vm's is to be able to run a virtual guest (windows, Linux, mac etc.), fits into memory, easily deleted, erased.....without affecting your host.
important question indeed and no be so fast with conclusions here, VW installed on encrypted virtual disk will in fact spy on you and write your important data un ecrypted on hard disk. if you willing to take such risk, then use it.
-
....the point of vm's is to be able to run a virtual guest (windows, Linux, mac etc.), fits into memory, easily deleted, erased.....without affecting your host.
important question indeed and no be so fast with conclusions here, VW installed on encrypted virtual disk will in fact spy on you and write your important data un ecrypted on hard disk. if you willing to take such risk, then use it.
- whats VW?
- could you read your reponse back to yourself and rephrase it...not sure what your point is..
- encryption isn't vmware / virtualisation..
-
with a VM you can
spawn multiple O/S
isolate all your applications from potential attacks (virtual firefox browser)
test your l337 viruses before deployment
change up your browser fingerprint (but not hardware fingerprint)
spawn truecrypt encrypted hidden O/S (but it leak info)
spawn a pf filter firewall tor server, use another instance to connect to it for further paranoia
...???
profit
virtualbox is good. set it up, then spawn your Open/FreeBSD virtual box and it's a complete fortress nothing can break it's jail
-
....the point of vm's is to be able to run a virtual guest (windows, Linux, mac etc.), fits into memory, easily deleted, erased.....without affecting your host.
important question indeed and no be so fast with conclusions here, VW installed on encrypted virtual disk will in fact spy on you and write your important data un ecrypted on hard disk. if you willing to take such risk, then use it.
- whats VW?
- could you read your reponse back to yourself and rephrase it...not sure what your point is..
- encryption isn't vmware / virtualisation..
I've been using VMware for 10 years or so, till bad information become available related to VMware for LInux.
first there is no reason and no enhancement in security in creating VM disk on unencrypted hard disk volume. you creating first virtual encrypted disk with program like truecrypt, then mounting it and creating VM disk on that encrypted volume, then installing VM operating system on that last volume. that way all your VM encrypted. any time you can dismount virtual disk and all your VM safe. Very convenient, BUT VMware for example will write cash from your VM installed on encrypted virtual disk on you your hard disk unencrypted and you will not be even aware of this. It is serious security breach. once I mounted my hard disk in Linux and what a surprise a lot of VMware cash was on my hard disk unencrypted email and other things. you cant see that happen if you always working from Windows. no one security minded LInux distro will include any VM software in it.
VM seems like convenient thing, so the same for someone who want to spy on you. I've been on net since x25, there was no Windows and Internet at this time, so I would say stay away from VMs.
sorry my english
-
Tranz, you know that VMware isn't the only virtualization software out there, right? There's VirtualBox, Qemu, KVM and others too. Are you just assuming that they all share the exact same security flaws?
-
BUT VMware for example will write cash from your VM installed on encrypted virtual disk on you your hard disk unencrypted and you will not be even aware of this. It is serious security breach. once I mounted my hard disk in Linux and what a surprise a lot of VMware cash was on my hard disk unencrypted email and other things. you cant see that happen if you always working from Windows. no one security minded LInux distro will include any VM software in it.
You're assuming that the host has a HDD, some of us are running VM systems HDD free. ;)
-
Tranz, you know that VMware isn't the only virtualization software out there, right? There's VirtualBox, Qemu, KVM and others too. Are you just assuming that they all share the exact same security flaws?
right, I'm just assuming. but if there is better and def more secure options available, like Liberte Linux for example and it is even more simple to use and install then why to use any VMs. why then to take a risk and use any of those. if you can buy real notebook for 300 backs, why any one would need virtual one, in same box with updates and security concern, just headache.
-
BUT VMware for example will write cash from your VM installed on encrypted virtual disk on you your hard disk unencrypted and you will not be even aware of this. It is serious security breach. once I mounted my hard disk in Linux and what a surprise a lot of VMware cash was on my hard disk unencrypted email and other things. you cant see that happen if you always working from Windows. no one security minded LInux distro will include any VM software in it.
You're assuming that the host has a HDD, some of us are running VM systems HDD free. ;)
I'm not that much smart, but thanks sound good
-
- for windows, logs are written to where the vm program files are installed, plus the user profile directory.
- the vm guest specific logs should be in the same location as the .vmdk and related files.
http://kb.vmware.com/kb/1021806
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021806
-
I think it's a moot point either way, because most people who are using a VM route are going to be using some form of full disk encryption. That being said, liberte should be fine for just about anyone.
Though, ideally as a vendor or if you are really paranoid:
http://xqz3u5drneuzhaeo.onion/users/secureconfig/tutorial.html
is where you want to be at, minus polipo.
-
Ok, I'm still not entirely sure why a vendor would want this, but theoretically would you do something like this:
- Create a hidden drive (on a memory stick) with TrueCrypt
- Run a Linux OS, probably OpenBSD
- Use TOR for everything online and PGP encryption for everything you send
So... Where does a VM fit into that? ???
-
http://dkn255hz262ypmii.onion/index.php?topic=8573.0
-
Not all virtualization technology is equal in the security department. This is true for multiple different reasons. First of all I hear from good hackers that full hardware virtualization systems like VMware and Virtual Box are harder to break out of than OS virtualization solutions like freebsd jails. Of course, you can layer multiple types of virtualization. Second of all, between the full hardware virtualization solutions there are differences in security based on the correctness of the hypervisor. I have heard that VMware and Virtualbox are so complex that their hypervisors are pretty much ensured to be penetrated by any talented hacker, they probably have plenty of 'jail breaking' flaws waiting to be discovered and exploited. However, this does require a talented attacker and even if there is a talented attacker using virtualization like this can buy you time (in which to detect them with intrusion detection software) and cost the attacker more resources (they still need to find an additional vulnerability to break out of the hypervisor). Of all the solutions for virtualization I have heard the best things about Xen as far as security is concerned, Qubes is an OS based on the xen hypervisor but I think they use an even leaner version to try to lower complexity and increase correctness (more complexity equals less correctness, as a general rule of thumb).
I doubt many law enforcement level attackers can break out of Virtual Box or even VMware hypervisor, even the ones talented enough to do basic hacking attacks against servers / sites and such.
-
of course it is matter of personal preferences what to use and finding a balance between life and security. at the end of the day in my book only two things are really matter - NEVER meet customer in person and NEVER keep any encrypted info on hard disk or were it can be located by some one. why not to meet? after meeting he can provide enough shit to get you arrested, even if you were talking about weather only. that can lead to discovery of encrypted info and bad things can happen, for example if you in UK it is already enough to get a jail term, in case if you will refuse to disclose the password.
-
Of all the solutions for virtualization I have heard the best things about Xen as far as security is concerned, Qubes is an OS based on the xen hypervisor but I think they use an even leaner version to try to lower complexity and increase correctness (more complexity equals less correctness, as a general rule of thumb).
Would you recommend using qubes instead of OpenBSD for enhanced security and privacy?
-
I've been using VMware for 10 years or so, till bad information become available related to VMware for LInux.
first there is no reason and no enhancement in security in creating VM disk on unencrypted hard disk volume. you creating first virtual encrypted disk with program like truecrypt, then mounting it and creating VM disk on that encrypted volume, then installing VM operating system on that last volume. that way all your VM encrypted. any time you can dismount virtual disk and all your VM safe. Very convenient, BUT VMware for example will write cash from your VM installed on encrypted virtual disk on you your hard disk unencrypted and you will not be even aware of this. It is serious security breach. once I mounted my hard disk in Linux and what a surprise a lot of VMware cash was on my hard disk unencrypted email and other things. you cant see that happen if you always working from Windows. no one security minded LInux distro will include any VM software in it.
VM seems like convenient thing, so the same for someone who want to spy on you. I've been on net since x25, there was no Windows and Internet at this time, so I would say stay away from VMs.
sorry my english
If you have been using VMWare for 10+ years then you should know a little better. The VM will only write data into the folder of the disk (cache or otherwise) on which the VM resides. If perhaps this is a USB drive this will remain on the USB drive and NOT the local storage. This being said if you encrypt the VM from within the VM using truecrypt (as you should for purposes of SR) then there may be logs stored outside the vm and cache while it is running but they would not indicate anything more than state changes of the VM as well as the virtual memory and file locking, but once the VM is shut down and closed from VMWare workstation/player those files are deleted. The only exception being the app caching however, that is still stored on the USB key and NOT on the hosting machine and doesn't provide much in the means of useful data. The data if any on the hosting machine would only point to having a vm at one point running on a USB key, this is not in any way a security issue. Simply having evidence of running a VM on a machine is not information that would be useful for incriminating anyone as it's very commonplace for people to install software in a vm to see how it will react before installing it on the hosting system.
-
how does it all matter. using VMs is completely impractical. it is I would say suicidal to have such kind of things on your hard disk. for example, you going to travel, your notebook can be detained for 2-3 days in airport, just because they don't like you. your Linux on pen drive is far more simple and leaving you with much less security concerns. Encrypted disk suppose to save you from trouble - encrypted disk means you are in big troubles.
I have 3 computers in my office and one day, when I saw that virtual machines start mashrumig I said myself, - that is enough. I want my life back.
my point is that if you have an option which is more simple, which will keep you less concerned, more secure, then what for do you need all those VMs.
-
Please forgive this uber noob question, but what is the point in setting up a Virtual Machine, they can't make your connection any more secure/anonymous can they?
My understanding was they gave you the ability to wipe your machine (but keep all progs) in like 2 minutes, am I missing something?
I mean I guess you could wipe your machine after closing TOR each time, so if any fucker has gotten some virus to you while you were online... is that it?
Please someone bring me up to speed here, thanks! ;D
I'm surprised no one else mentioned this...
The reason why I run tor in a VM is to prevent leakage. My VM is secured in such a way that regular "clear net" traffic is blocked. If you run the Tor browser at the same time as your regular browser, for example, you leak information about your connection since you have a regular browser session open. DNS queries are the worst for this.
A virtual machine keeps a logical separation between your regular computing environment and your "Silk Road computing environment." Moreover, it also allows for another layer of security which adds another layer to a defense-in-depth strategy.
As a side note, I find that my secured VM has much, MUCH better Tor performance than Vidalia/Aurora. I never have problems connecting to SR.
-
Ok, so I contacted Theo De Raadt to ask him about BSD security for 'democracy activists' and other anonymity enthusiasts (we being droogs dealers/buyers). I was surprised he actually answered without telling me to fuck off as he's legendary for being a total neckbeard.
His answer for Virtualization (Virtualbox/VMware/QEmu/Xen ect) is that it's completely insecure as fuck, and if you use it, you're a complete fool. The received security knowledge is that by using VMs, an attacker needs to do the following in order to compromise your security:
-break into user account
-escalate to root
-break out of jail to Virtualbox
-root the host system
But that is not the case. Because VMs are primarily for testing and application meddling before deployment, they are coded quickly and definitely not for security. OpenBSD is guaranteed security when running on the supported hardware directly because they've already audited how the software interacts with that hardware and confirmed there are no exploits.
With VM software, you have no clue how it will interact because now your hardware is shit emulation that can be escalated. He claims they get OpenBSD security breaches all the time reported from people using Virtualbox and his answer is 'we don't support x86 shit stacks upon already shit x86 platforms' and the same problem can never be recreated using identical hardware. The bug/security hole isn't in OpenBSD, it's in the VM emulation of that particular hardware device which allows for escalation. In fact he doesn't even recommend chrooting as it's basically useless to advanced attackers and a fall sense of security when clever partitioning and multiple systems can be used.
So theoretically it sounds awesome confining all your stuff into compartmentalized bubbles to isolate internet facing applications but in reality you are making yourself even more insecure since you now are using unaudited hardware emulation and relying on that for security. Encryption is also not safe while running in a virtual machine.
To properly isolate applications you need different machines running real hardware. Since OpenBSD just needs 64megs mem to run Tor/Arm or even less to act as a firewall you could buy shitty old used server racks and stack them to host your internet facing applications behind a properly configured firewall that basically jails them the correct way preventing escalation like how most banks operate with critical applications like databases all on different servers. A 2.6ghz 1G ram old dell server is $40 where I live which I configured to pf firewall/router. Behind that my regular OpenBSD laptop running softraid0 encryption with truecrypt containers. Sensitive internet applications like Tor simply put on a new partition with zero access rights.
No emulation that relies on the security of Xen or Virtualbox developers running unaudited code, no virtual machine encryption leaks, no root escalation through OpenBSD zero day (does OpenBSD 0day even exist?) as the pf firewall and intrusion detection system catches it before it can be deployed. Compile everything through ports for stability and security audited guarantee.
This of course for Julian Assange type maximum security if you're concerned motivated agencies may come after you
-
does OpenBSD 0day even exist?
Your post is excellent and gives me a lot of material to chew on, but this part had me laughing my ass off (in a good way).
-
You can also go total neckbeard commando text only and just dual boot OpenBSD 5.0 + something else (Debian? Win7?).
Your encrypted OpenBSD 5.0 partition does nothing but drugs business, hacking, sending threats to the NSA ect. You don't need Xorg you can do everything command line like encrypting/decrypting emails and sending them through Tor from your @tormail account. Type 'mail' in the command line and get used to working with it (now you have zero email exploits). Then you have persistence, and aren't constantly grabbing new guard nodes which is a slight anonymity flaw of using Live CDs like Tails/Liberte. For internet use lynx in your business only O/S. This forum doesn't look as nice using lynx but still works. If the NSA ever (unlikely/tinfoil hat) compromised it and hid 0day firefox, IE and Aurora exploits it wouldn't effect you in your bomb shelter operating system from the past nobody can break.
Since BSD is transparent you can cron job to nuke absolutely all evidence (history, emails, whatever) there's no bullshit MS page file or system restore backups saving critical information. Then reboot back into your Win7 machine to look at porns, play games, whatever you want.
This is a good softraid tutorial on setting it up
http://geekyschmidt.com/2011/01/19/configuring-openbsd-softraid-fo-encryption
Then of course encrypt the entire HDD for fun an profit with truecrypt, and use truecrypt containers for crazy sensitive stuff like ordering info or use LUKS, or keep it on a separate USB encrypted key
-
how does it all matter. using VMs is completely impractical. it is I would say suicidal to have such kind of things on your hard disk. for example, you going to travel, your notebook can be detained for 2-3 days in airport, just because they don't like you. your Linux on pen drive is far more simple and leaving you with much less security concerns. Encrypted disk suppose to save you from trouble - encrypted disk means you are in big troubles.
I have 3 computers in my office and one day, when I saw that virtual machines start mashrumig I said myself, - that is enough. I want my life back.
my point is that if you have an option which is more simple, which will keep you less concerned, more secure, then what for do you need all those VMs.
Obviously for SR purposes you would not want your VM stored on a local HDD, this of course would be stupid however on a USB drive it's quite practical and gives you a reasonable level of isolation preventing potentially incriminating data from residing on the hosting machine which is the entire purpose. The purpose isn't to make the machine more secure from some sort of hacking threat, it's to contain incriminating data and make it easily disposeable in the unfortunate event that you feel you may be under threat by LE or in the other case where they are able to obtain said USB drive to make the data forensically impractical (or impossibe) to retrieve. A VM with high levels of encryption accomplishes that goal quite easily and in a practical manner. The other piece is the practicality of cracking down on on buyers/vendors (see below for more on this).
You can also go total neckbeard commando text only and just dual boot OpenBSD 5.0 + something else (Debian? Win7?).
Your encrypted OpenBSD 5.0 partition does nothing but drugs business, hacking, sending threats to the NSA ect. You don't need Xorg you can do everything command line like encrypting/decrypting emails and sending them through Tor from your @tormail account. Type 'mail' in the command line and get used to working with it (now you have zero email exploits). Then you have persistence, and aren't constantly grabbing new guard nodes which is a slight anonymity flaw of using Live CDs like Tails/Liberte. For internet use lynx in your business only O/S. This forum doesn't look as nice using lynx but still works. If the NSA ever (unlikely/tinfoil hat) compromised it and hid 0day firefox, IE and Aurora exploits it wouldn't effect you in your bomb shelter operating system from the past nobody can break.
What are you protecting against? This isn't a literal question but one that should always be asked and used to determine the practicality of using a solution like this. Sure there are people looking to maliciously attack the average user for things like credit card fraud and access to personal data for identity theft and other various things, corporate espionage etc the list is endless however for the purposes of SR this is completely impractical. This security threat is not in any way unique to the community here, it exists for all of the internet users.
Secondly and more importantly nobody is going to waste their time to go after buyers who buy for personal use. Why you say? It's VERY simple.
Assuming there are 150,000 users on SR (round numbers) that equates to less than %0.003 of the worlds population not only is this an extremely small amount but the 'reward' for busting or otherwise cracking down on this percentage is minimal at best. Think about how many people order an once of weed here and there and use SR for very little else. What goverment agency is going to spend the kind of resources it would take to make that arrest? None it's simply not practical and exceptionally difficult in the first place.
So we move on to the vendors, who would be much more 'rewarding' targets however there are less than 250 vendors on SR! This equates to less than %0.000004 of the worlds population so bearing this in mind again WHO would bother? It would be a largely unrewarding waste of time to attempt to make this sort of bust.
I'm not saying that VM's are the most secure out there but they do offer an additional layer of security from a data protection standpoint as it relates specifically to SR and LE. While all valid security concerns in this thread they are not unique to SR nor are they less of a threat anywhere else. While I am certainly in favor of being secure there is a point at which you are doing it for the sake of doing it as it adds less and less practical value. Sure is it 'cool' to have a truly unhackable secure setup? Absolutely, and really quite fascinating, but at the same time what do you really gain? Once you pass that point where you've done 'enough' to secure things in a reasonable fashion all you are doing is increasing your bragging rights because nobody will bother trying to attack you anyways.
-
Theo De Raadt is one security researcher and his views on virtualization being used for isolation / security are not held by all security professionals, for example the team that made Qubes would obviously disagree with him. My favorite thing to say to people who are rabidly against virtual isolation is that if correctness is the only way to be secure people should make a correct hypervisor because then the attacker wont be able to break out of it ;). Also OpenBSD is big on correctness via constant code audits by professionals, but a significant number of security experts will be quick to point out that OpenBSD has pretty shitty support for security via isolation, it is kind of controversial that they have no mandatory access control systems and its support for virtualization technology is shitty as well. Don't discount the real security advantages of virtualization being used for isolation based on the words of one person, even if he is a world leading security expert, because others of the same caliber disagree with his position.. Defense in depth is imo the best strategy and it is a shame that the openBSD team thinks they can ignore isolation in favor of code correctness, OpenBSD may have very few remote code executions and a history of high correctness but when you run OpenBSD you will be running other non-audited applications that have plenty of zero day vulnerabilities. It would be nice if you could isolate them with mandatory access control systems and virtual machines, but good luck doing that on OpenBSD.
-
His answer for Virtualization (Virtualbox/VMware/QEmu/Xen ect) is that it's completely insecure as fuck, and if you use it, you're a complete fool. The received security knowledge is that by using VMs, an attacker needs to do the following in order to compromise your security
Theo and the OpenBSD people have never been big fans of virtualization or mandatory access control systems being used for security. This is their opinion and it isn't shared by all expert level security researchers, it is actually fairly controversial in security circles that OpenBSD has no MAC system and I personally find it annoying that they have very little virtualization support. Qubes is an OS that was also made by expert level security researchers and they focused on the isolation route.
-break into user account
-escalate to root
-break out of jail to Virtualbox
-root the host system
Really that is all that you need to do? To hack the system all you need to do is compromise the system? That list of steps adds no additional information and is inherently obvious. The thing is to break out of the jail to virtualbox, or to break out of virtualbox to the host system, the attacker needs to find an additional vulnerability. Finding an additional vulnerability in the hypervisor of virtualbox or vmware may not be an extremely difficult thing to do because they use overly complex code bases. The Qubes people went with Xen and I think it probably has a less complex and more correct hypervisor that will be harder to break out of. SEL4 is a formally verified microkernel, some security experts have said that microkernels are essentially hypervisors, so if the assumptions the SEL4 proof is based on hold to be true and everything was correctly formally verified, it is (I think) provably impossible to break out of the isolation provided by SEL4. That goes back to what I said before about having a correct hypervisor. The only real argument against using virtualization in this way is that an attacker can break out of the isolation if they find an additional vulnerability, but guess what they still need to find/spend an additional zero day which buys you time in which to detect them and if you use a correct hypervisor they wont be able to break out of it anyway.
But that is not the case. Because VMs are primarily for testing and application meddling before deployment, they are coded quickly and definitely not for security. OpenBSD is guaranteed security when running on the supported hardware directly because they've already audited how the software interacts with that hardware and confirmed there are no exploits.
VMs are coded with security in mind as one of the potential uses. Sandboxes are a wide known security technique. Java uses a VM that gives it security advantages over non-interpreted languages. VMs and security go hand in hand actually. VM are also used for analysis of viruses and they are used so the virus can not effect the host system. VMs are also used in hosting environments so if one customer is pwnt the attacker can not as easily damage other customers.
OpenBSD is not guaranteed security, it hasn't even been formally verified so there is not a proof of correctness. It is highly correct though because it has been audited in depth by a large number of security experts and really good coders. OpenBSD probably has less vulnerabilities left in it than anything else that hasn't been formally verified. Of course when you use OpenBSD you will be installing all kinds of additional things that have not been nearly as highly audited and could still contain remote code execution vulnerabilities, such as firefox. OpenBSD gives an additional layer of protection from these applications being attacked in the form of ASLR and it has two tools for isoation Systrace and chroot, but it doesn't have a mandatory access control system and it doesn't support much virtualization technology. This is why I prefer to run OpenBSD as a virtual machine guest instead of the host system.
With VM software, you have no clue how it will interact because now your hardware is shit emulation that can be escalated. He claims they get OpenBSD security breaches all the time reported from people using Virtualbox and his answer is 'we don't support x86 shit stacks upon already shit x86 platforms' and the same problem can never be recreated using identical hardware. The bug/security hole isn't in OpenBSD, it's in the VM emulation of that particular hardware device which allows for escalation. In fact he doesn't even recommend chrooting as it's basically useless to advanced attackers and a fall sense of security when clever partitioning and multiple systems can be used.
Well you can virtualize a 64 bit OS if you have a CPU that supports hardware virtualization. Of course OpenBSD isn't as secure on 32 bit systems, ASLR on such such systems can be brute forced. The same exact problem is created by using a 32 bit OS in any case, ASLR on 32 bit OS is not secure. OpenBSD has a more secure version of chroot than most other operating systems. And yes if you are up against the CIA or NSA they will cut through all the layers of isolation that you throw at them probably near instantly and without being detected, but if you are up against script kiddies to intermediate hackers a single layer of isolation with virtual machines will imo probably be enough to prevent them from breaking out of isolation. If you are up against advanced hackers who are not CIA or NSA level they will still probably eventually be able to break out of all layers of isolation that you throw at them, but in this case isolation still buys time in which you can detect them with intrusion detection software.
So theoretically it sounds awesome confining all your stuff into compartmentalized bubbles to isolate internet facing applications but in reality you are making yourself even more insecure since you now are using unaudited hardware emulation and relying on that for security. Encryption is also not safe while running in a virtual machine.
Please provide me with logs from Theo or any citation that claims it is not safe to use encryption in a virtual machine. Also I have never heard of virtualization decreasing security before, although I have heard from a number of security experts that vulnerabilities in hypervisor and other things can allow an attacker to break out of the isolation if they can discover and exploit the vulnerabilities. I have also heard from security experts that isolation is the best current technique for security and correctness and randomization are not currently at a state where they can be relied on. I have also heard from security experts that isolation like this is worthless and correctness is the only way to go (of course I guess we just need a correct hypervisor for virtualization based isolation like this to be the way to go then).
To properly isolate applications you need different machines running real hardware. Since OpenBSD just needs 64megs mem to run Tor/Arm or even less to act as a firewall you could buy shitty old used server racks and stack them to host your internet facing applications behind a properly configured firewall that basically jails them the correct way preventing escalation like how most banks operate with critical applications like databases all on different servers. A 2.6ghz 1G ram old dell server is $40 where I live which I configured to pf firewall/router. Behind that my regular OpenBSD laptop running softraid0 encryption with truecrypt containers. Sensitive internet applications like Tor simply put on a new partition with zero access rights.
Yes I agree that hardware based isolation is better but ignoring virtualization based isolation is a bad mistake imo. Banks use hardware chips with isolation layers and they have still been penetrated by hackers. But just because the most leet hackers in the world can pwn banks doesn't mean they should throw in the towel and use no security technology at all.
No emulation that relies on the security of Xen or Virtualbox developers running unaudited code, no virtual machine encryption leaks, no root escalation through OpenBSD zero day (does OpenBSD 0day even exist?) as the pf firewall and intrusion detection system catches it before it can be deployed. Compile everything through ports for stability and security audited guarantee.
This of course for Julian Assange type maximum security if you're concerned motivated agencies may come after you
Yes there have been OpenBSD zero days before and no there is no mathematic proof that there never will be again. Also you run unaudited applications in OpenBSD all the time. Also if you add layers of isolation you buy more time in which to detect an intrusion, intrusion detection software and isolation go hand in hand. Show me any citation about virtual machines and encryption leaks. Also there could be a vulnerability in the code of the pf firewall, so it shouldn't be used because a leet hacker might be able to break out of the isolation is provides ;).
-
You can also go total neckbeard commando text only and just dual boot OpenBSD 5.0 + something else (Debian? Win7?).
Your encrypted OpenBSD 5.0 partition does nothing but drugs business, hacking, sending threats to the NSA ect. You don't need Xorg you can do everything command line like encrypting/decrypting emails and sending them through Tor from your @tormail account. Type 'mail' in the command line and get used to working with it (now you have zero email exploits). Then you have persistence, and aren't constantly grabbing new guard nodes which is a slight anonymity flaw of using Live CDs like Tails/Liberte. For internet use lynx in your business only O/S. This forum doesn't look as nice using lynx but still works. If the NSA ever (unlikely/tinfoil hat) compromised it and hid 0day firefox, IE and Aurora exploits it wouldn't effect you in your bomb shelter operating system from the past nobody can break.
Since BSD is transparent you can cron job to nuke absolutely all evidence (history, emails, whatever) there's no bullshit MS page file or system restore backups saving critical information. Then reboot back into your Win7 machine to look at porns, play games, whatever you want.
This is a good softraid tutorial on setting it up
http://geekyschmidt.com/2011/01/19/configuring-openbsd-softraid-fo-encryption
Then of course encrypt the entire HDD for fun an profit with truecrypt, and use truecrypt containers for crazy sensitive stuff like ordering info or use LUKS, or keep it on a separate USB encrypted key
Not having persistent entry guards is actually a major anonymity flaw there is nothing slight about it. I think liberte actually does have persistent entry guards but amnesia doesn't.
-
security in general does not provide any security and seriously will interfere with normal life, hardly there are many people who can have enough discipline to follow some complicated system for long. I'm one of them. security have to be addressed according to threat. here is what I would consider as a treats, arranged in danger level
1 physical access of adversary to your encrypted data. people been tortured for that. remember your password, that can be handy in such situation.
2 sniffing and injections on your local network. does no matter on which OS you are TCP/IP is the same.
3. security of OS
here is how I would address those treats:
1. BOOT from flash card inserted into small USB card reader, small card easy to hide. finish your work and hide that card very well.
2. sniffing and injections on local network. top level programmers working with companies like Qualcom and others been hacked this way. to prevent this happen use VPN with double key, rent and maintain your own dedicated server and install private commercial version of VPN. losing data on local network very common thing. worst thing is that, such attack can point attacker to your physical location. see (1)
3. use hardened Linux like Liberte or other or make your own, no big deal. Any Linux OS which becoming mainstream is not secure and I perdonally will never use.
not related to computers but worth to mention - I would consider serious security treat reappeared customer, who suddenly want to go in business again. If he will order irregularly, or start talking of doing big loads, I would drop him right away.
be safe
-
how does it all matter. using VMs is completely impractical. it is I would say suicidal to have such kind of things on your hard disk. for example, you going to travel, your notebook can be detained for 2-3 days in airport, just because they don't like you. your Linux on pen drive is far more simple and leaving you with much less security concerns. Encrypted disk suppose to save you from trouble - encrypted disk means you are in big troubles.
You don't know what you are talking about. If you are worried about what is practical instead of what is secure then you are in the wrong line of work. Also encryption is your friend and it works just as well on a hard disk as it does on a USB. Linux on a pen drive is a good idea but all of the preconfigured live operating systems I have seen are toys when it comes to security. There are a lot of security toys. Not having an encrypted disk means you are in big troubles.
I have 3 computers in my office and one day, when I saw that virtual machines start mashrumig I said myself, - that is enough. I want my life back.
You wont have a life when you are traced by the DEA when they exploit a firefox vulnerability. If the same attacker couldn't break out of your virtualization systems hypervisor or pwn the Tor application you will really be kicking yourself in the ass when you are in prison.
my point is that if you have an option which is more simple, which will keep you less concerned, more secure, then what for do you need all those VMs.
No your solution of using linux on a pen drive is not inherently more secure. Of course you could have a pen drive that has a linux host on it and still use layers of isolation.
Obviously for SR purposes you would not want your VM stored on a local HDD
Why not, you encrypt your HDD don't you?
this of course would be stupid however on a USB drive it's quite practical and gives you a reasonable level of isolation preventing potentially incriminating data from residing on the hosting machine which is the entire purpose.
I fail to see the difference between an encrypted HDD and an encrypted USB drive that you mention. There are differences with security implications, but in these cases HDD is more secure. If you know what you are doing, encryption used on HDD and on USB drive will offer the same security, there is no 'of course this would be stupid' about it.
Also you are correct in your description of isolation, but the goal of virtualization being used in the way I mention is not so much to prevent incriminating data from being stored on the host system (lthough it will help with this also) but rather to prevent an attacker who pwns one of your internet facing applications from spreading to other applications or items of interest / getting to the host OS. That is the main security benefit of using virtualization like this imo. Encryption and data destruction programs have the main goal of preventing incriminating information on your HDD from being gathered by an attacker.
The purpose isn't to make the machine more secure from some sort of hacking threat, it's to contain incriminating data and make it easily disposeable in the unfortunate event that you feel you may be under threat by LE or in the other case where they are able to obtain said USB drive to make the data forensically impractical (or impossibe) to retrieve. A VM with high levels of encryption accomplishes that goal quite easily and in a practical manner. The other piece is the practicality of cracking down on on buyers/vendors (see below for more on this).
No the main purpose of using isolation like this is to protect from hacking threats. There is an added advantage that it contains incriminating data, but you should be using encryption and data destruction programs for the purpose you mention.
What are you protecting against? This isn't a literal question but one that should always be asked and used to determine the practicality of using a solution like this. Sure there are people looking to maliciously attack the average user for things like credit card fraud and access to personal data for identity theft and other various things, corporate espionage etc the list is endless however for the purposes of SR this is completely impractical. This security threat is not in any way unique to the community here, it exists for all of the internet users.
You are protecting from hackers. It is just as likely users of SR will be targeted as it is that users of a given carder or any other illegal forum will be targeted. Carders say the same shit about drug forums. Everyone uses cognitive defense mechanisms when they are putting their life on the line, but a truly smart person will try to not do this because it weakens security. Yes the threat exists for all internet users but the users here are far more likely to be targeted with sophisticated technical attacks than the average internet user is.
Secondly and more importantly nobody is going to waste their time to go after buyers who buy for personal use. Why you say? It's VERY simple.
Sure they will a statistic is a statistic. Plus buyers here are probably parts of IRL drug networks.
Assuming there are 150,000 users on SR (round numbers) that equates to less than %0.003 of the worlds population not only is this an extremely small amount but the 'reward' for busting or otherwise cracking down on this percentage is minimal at best. Think about how many people order an once of weed here and there and use SR for very little else. What goverment agency is going to spend the kind of resources it would take to make that arrest? None it's simply not practical and exceptionally difficult in the first place.
Government agencies exist to fund themselves. The agents get pay checks regardless of who they bust. They are looking for numbers. SR has a large number of drug users on it and it offers a conveniant way to target large numbers of people because it is centralized in many ways. Please get out of your cognitive defense mechanisms and your distorted view of government and police before it lands your ass in jail. Government agencies don't spend resources they steal resources from the people. The government will be very happy to say they need to steal a few extra million tax dollars to bust the users on Silk Road and the personal users who are busted will be talked about as international drug traffickers who are part of a major drug network that uses military grade technology to evade police and launder money etc. When you read of big busts in the news etc in many of those cases the people actually busted are fairly small time but the stories are played up so much and so dramatized that it paints a false picture.
So we move on to the vendors, who would be much more 'rewarding' targets however there are less than 250 vendors on SR! This equates to less than %0.000004 of the worlds population so bearing this in mind again WHO would bother? It would be a largely unrewarding waste of time to attempt to make this sort of bust.
If you make any subset of drug dealers based on any characteristic you can say that they are a small percentage of the total drug dealing population, but obviously drug dealers are targeted and sent to prison. So your entire logic is flawed.
I'm not saying that VM's are the most secure out there but they do offer an additional layer of security from a data protection standpoint as it relates specifically to SR and LE. While all valid security concerns in this thread they are not unique to SR nor are they less of a threat anywhere else. While I am certainly in favor of being secure there is a point at which you are doing it for the sake of doing it as it adds less and less practical value. Sure is it 'cool' to have a truly unhackable secure setup? Absolutely, and really quite fascinating, but at the same time what do you really gain? Once you pass that point where you've done 'enough' to secure things in a reasonable fashion all you are doing is increasing your bragging rights because nobody will bother trying to attack you anyways.
Don't underestimate your adversary.
-
Well if you want to argue with infamous neckbeard Theo De Raadt and developers on the OpenBSD mailing list with your theory of VMs provide 'extra' security through isolation feel free to do so. I asked him about amd64 VM protection and got basically the same 'go fuck yourself' answer.
Here's his responses to "Virtualization makes your system more secure.."
x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.
if the actual hardware let us do more isolation than we do today, we would actually do it in our operating system. The problem is the hardware DOES NOT actually give us more isolation abilities, therefore the VM does not actually do anything what the say they do
While x86 hardware has the same page-protection hardware that an IBM
390 architecture machine has, modern PC machines are a mess. They are
architecturally so dirty, that parts of the video, keyboard, and other
IO devices are interfaced with even to do simple things like context
switching processes and handling interrupts. Those of us who have
experience with the gory bits of the x86 architecture can clearly say
that we know what would be involved in virtualizing it, and if it was
so simple, we would not still be fixing bugs in the exact same area in
our operating system going on 12 years.
We know what a VM operating system has to do to deal with the PC
architecture. It is too complex to get perfectly right.
And now you've entered into the layered approach where *any error* in
the PC model exposed to the client operating system is not just a
crashing bug -- it is now exploitable.
It might be nice, but it is stupid. And anyone who thinks there is
any security advantage at any level knows nothing about PC
architecture..
A few of us just spent some time again debugging an application level
problem ... and once again realized that the application was running
on OpenBSD inside the Innobox's VirtualBox VM.
Argh.
Sun owns InnoTek now because I think they wanted a VM product, but
the product is badly broken.
When that VM is running, we end up with bugs that make it quite
clear that cpu registers are being corrupted in some instances.
We don't know how other operating system products continue running
when the userland ecx register gets clobbered on a return from a page
fault, but at least people should be aware that there is likely some
security risk from running that product.
That VM does not emulate the x86 correctly, (either).
This massive move towards VM use is a worrying trend and I am scared
of the side effects we will face from so many people (essentially)
choosing to run 3 operating systems instead of 1 ... and doing this
when their guest choice is 'OpenBSD for security'. I really wonder
how people arrive at such a position... without logic or technological
understanding, I suppose.
The claims of Truecrypt possible leaks to the host O/S page and swap/mem while used inside a VM come from seclists.org, bruce schnier's blog, and the truecrypt mailing list.
When I asked De Raadt what he would recommend his answer was of course legendary in asshole neckbeardishness 'man softraid' and a link to setting up isolated partitions in OpenBSD.
-
I will make a more detailed response to this soon, but for now just let me say that it is pointless to argue with the OpenBSD devs because they are religiously devoted to their security philosophy, but just realize that their ideas are not shared by at least some number of other security researchers who are just as validly called leading experts. For example, I would love to see what the Qubes team has to say in response to this. I like to use OpenBSD for the guest because it has 64 bit ASLR, nx bit, and a bare bones highly correct base install.
You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.
He is absolutely deluded to think that you shouldn't add layers for an attacker to go through, that they otherwise wouldn't have to go through, simply because they may be able to get through them. Of course most hypervisors are not perfectly correct (other than maybe SEL4 if it counts as a hypervisor), but that doesn't change the fact that they add an additional layer for your adversary to penetrate.
Is Theo aware that this discussion is in regards to hiding your IP address from an attacker? He really should be aware of the wider topic of discussion before he comments on the technique.
Anyway the argument I am seeing here is "virtualization isolation is worthless because virtualization technology is not perfectly correct, and only correctness matters". This is such a shitty way to look at things. OpenBSD hasn't been formally verified so you shouldn't use it because it may have security vulnerabilities that an attacker can exploit if they spend enough time looking for them. I wonder what he has to say in reply to that.
if the actual hardware let us do more isolation than we do today, we would actually do it in our operating system. The problem is the hardware DOES NOT actually give us more isolation abilities, therefore the VM does not actually do anything what the say they do
First of all this sentence makes little sense to me so it is hard to reply to it. I know little about hardware isolation so I can not really comment on this yet I need to read some papers on it that I have but have not had the time to read. I am thinking of things like the Tor routers that run Tor on a purpose specific device rather than requiring the user to run it on their operating system, however I think he is probably talking about things like AMD-v. Please ask him to clarify this sentence and go into technical detail.
While x86 hardware has the same page-protection hardware that an IBM
390 architecture machine has, modern PC machines are a mess. They are
architecturally so dirty, that parts of the video, keyboard, and other
IO devices are interfaced with even to do simple things like context
switching processes and handling interrupts. Those of us who have
experience with the gory bits of the x86 architecture can clearly say
that we know what would be involved in virtualizing it, and if it was
so simple, we would not still be fixing bugs in the exact same area in
our operating system going on 12 years.
I need more time to think on a response to this than I have right now, but I would like to mention that I am not even talking about virtualizing the x86 architecture but rather x86-64, although what he says may very well still hold true for that. Also now is a good time to mention the distinction between virtualization solutions like virtual box (full hardware virtualization) and systems like Xen (paravirtualization). I think that paravirtualization will avoid all of the potential problems Theo mentions here, and this now further strengthens my belief that Xen should be used over Virtualbox or VMware.
Also allow me to say that I am not an expert on virtualization or even on computers especially as compared to people like Theo, but I can recognize that as good at security as he is other people who are just as good as him or possibly even better (I can not tell) use different strategies than he does.
We know what a VM operating system has to do to deal with the PC
architecture. It is too complex to get perfectly right.
Well I am not an expert on this matter, but I think sel4 offers a provably correct layer of isolation in addition to using paravirtualization. I need to research this more before I make any definitive claims though.
And now you've entered into the layered approach where *any error* in
the PC model exposed to the client operating system is not just a
crashing bug -- it is now exploitable.
I don't follow his logic of how everything is now an exploitable bug please ask him to clarify for me. Layered approach aka defense in depth is favored by many security professionals. And again please inform him that this discussion is related to a technique for hiding your IP address from an attacker who roots your firefox VM, while using Tor in another VM and host only routing with firewall rules on the host.
It might be nice, but it is stupid. And anyone who thinks there is
any security advantage at any level knows nothing about PC
architecture..
That is a pretty big claim to make considering there are a ton of world leading security research teams who are focusing on using virtualization in this way for security advantages. Then again, Theo is a world leading security expert. He knows more than I do about computer security. So do people who disagree with him.
This massive move towards VM use is a worrying trend and I am scared
of the side effects we will face from so many people (essentially)
choosing to run 3 operating systems instead of 1 ... and doing this
when their guest choice is 'OpenBSD for security'. I really wonder
how people arrive at such a position... without logic or technological
understanding, I suppose.
He thinks it is a worrying trend. The people doing it think it is the future of computer security. I see Theos logic as being that virtualization being used for isolation like this is a bad idea because the virtualization technology is not perfectly correct and can be broken out of. My response to this sort of logic is that people should work on making a correct hypervisor then. Or that you shouldn't use OpenBSD because it isn't formally verified, sarcastically of course.
I will make a better more detailed response to this post soon I don't have time right now to spend the time required to think and research on a better post. Arguing with people of this caliber is a good way to look like a dumbass because they are widely recognized as leading experts, but I know that I have logic in my arguments and that others who are equally as impressive as Theo would also argue against him in similar ways as to how I have. However, I wish he was having this debate with the Qubes research team or the SEL4 people instead of me.
-
I need to read about the truecrypt and VM security thing before I comment on it.
-
Also keep in mind when you talk with security researchers like Theo and others, that they are quite probably imaging the adversary as being on the level of an intelligence agency. My opinion is that just because the NSA can pwn your isolation layers doesn't mean you shouldn't use them when they will prevent the feds from pwning your ass.
-
Please give me a link to the thing about virtual machines and truecrypt because I can't find a single thing about it despite lots of google.
-
While x86 hardware has the same page-protection hardware that an IBM
390 architecture machine has, modern PC machines are a mess. They are
architecturally so dirty, that parts of the video, keyboard, and other
IO devices are interfaced with even to do simple things like context
switching processes and handling interrupts.
Has Theo never heard of IOMMU? From Wikipedia:
An input/output memory management unit (IOMMU) enables guest virtual machines to directly use peripheral devices, such as Ethernet, accelerated graphics cards, and hard-drive controllers, through DMA and interrupt remapping. This is sometimes called PCI passthrough.[30] Both AMD and Intel have released specifications:
* AMD's I/O Virtualization Technology, "AMD-Vi", originally called "IOMMU".[31]
* Intel's "Virtualization Technology for Directed I/O" (VT-d).[32] Included in most but not all Nahalem based processors. [33]
I know Qubes uses IOMMU and that it is supported by Xen, not sure if it works with virtual box or full hardware virtualization though. I think this should offer isolation on the layer that Theo is currently bitching about. Also lack of IOMMU with SEL4 is one reason the Qubes dev gave with why they went with Xen instead of SEL4, even though SEL4 is provably correct at what it does.
This is really fairly cutting edge computer science / computer security shit and I can't claim to be an expert on these matters, but it is the stuff I am currently researching and trying to understand. In the past few months I have come to one conclusion though and it is that I was wrong to suggest Virtual Box be used for isolation, I should have suggested Xen and I will personally be switching from Virtualbox to Xen. Last I checked Xen is much more difficult to configure and use than Virtualbox is, for the average user. If this is still the case, if you decide to go with virtualbox or nothing, I would still suggest virtualbox and isolating network facing applications away from Tor with it. The feds are not the caliber of attacker that Theo is worried about when he discusses security issues, and I am not convinced of his apparent claims that using virtualization is not only worthless but also a huge security threat in and of itself (I would really love for him to explain this in deep technical detail).
-
Also you make it seem like your quoted responses from Theo are responses to you in particular, in relation to things that I in particular am saying, but I found those same exact quotes from him on a number of security and virtualization related discussion forums. I really would need to see the original questions asked to him to better understand his responses.
-
I had to make a new account, forgot old password :( and the email is abandoned.
Yes, these are all quotes from the openbsd mailing list about virtualization. I asked him regarding IP concealment through virtualization as like all of you it is relevant to my interests and he gave me a one line reply.
Judging from his response he must think I'm retarded to use virtualization for anything security related and his one line reply to me to 'man softraid' (lol) and separate internet facing applications on their own partitions, like a chrooted Tor daemon basically makes sense now after some research.
A $40 old computer lying around could do whatever you think virtualization does with real security which is running a router/pf firewall/carp/intrusion detection and protecting your inner systems from exposure through that, while mounting tor (on your inner laptop or whatever) in a chroot on a separate virtual partition using vnconfig.
vnconfig and virtual drives are essentially the same as using a VM for what we want (conceal your IP if anybody breaks in) except the difference is this virtual partition isn't being booted over buggy emulated hardware that hasn't been security audited whatsoever. vnconfig is integrated into OpenBSD and has been audited. Should an attacker breach tor somehow, they're now stuck on an encrypted virtual disk, on a separate partition in a chroot behind a firewall/NAT ect. so they'll only ever see internal IP addresses should they break out of chroot (which is incredibly easy to do.. chroot basically prevents applications from overloading mem and other problems, it's not really used for 'security' per se as anybody getting into a chroot can break out of it in a few easy steps according to these developers http://kerneltrap.org/Linux/Abusing_chroot)
After experimenting around with vnconfig making encrypted virtual disks and secure partitions I think I've managed to set up a pretty bulletproof tor session should the worst case scenario happen: NSA or Chineez government cracks/hax00rs tor, somehow the feds learn this method and use it to round us all up. Or worse my competitors find out this method and come after me :X
And of course only ever using the terminal (tmux is awesome!) for browsing, IRC (irssi) and everything else. I can fetch emails over tor from usenet I have sent to a nym mixmaster, decrypt them command line now with an easy script, talk on terminal jabber-otr, basically everything just needs a bit more effort to start but now it's no problem to use, and I can't believe I wasted so much time using X. I use nothing but in house OpenBSD encryption tools to encrypt the entire drive much like this tutorial: http://www.undeadly.org/cgi?action=article&sid=20110530221728 except I use Keydisk + high entropy passphrase as I don't want somebody to be able to just plug in a key and boot my system (Cops). I'm also looking into resurrecting the Anonym.os CD, except getting rid of xwindows and writing a clear manual how to use it. Even better a persistent encrypted USB drive that when plugged in can be booted without having to reboot the main comp, so somebody can walk into a computer cafe and use it.
Partly because of my interaction with BSD devs on IRC talking about their encryption setups. They'll tell you anything you want to know as long as you read a few man pages and aren't getting them to spoon feed you. Most of these crusty old IBM assembler coders have a good idea on how nearly bulletproof security can be achieved and most devs are not from the US, so no fans of the NSA. Ryan McBride is a good dev to talk to about ultra paranoid security setups for resisting your own governments attempts to compromise your setup.
Files and encrypted virtual partitions work in OpenBSD much like how truecrypt works (vnconfig -k ) so basically I am 100% neckbeard now using tmux 4 terminal screens to run my minature illegal empire and feels good man.
Loïc Duflot an expert in smashing out of X has basically said for a decade that X is not secure whatsoever no matter what tricks you do to isolate it. By it's very design it just can't be 100% secure. I'm betting Assange and Sabu both read their emails in terminal mail too. I do know Sabu burns custom Android ROMs on throwaway prepaid phones to update twitter and then wipes it, smashes it to pieces and launches the bits into the hudson river when he's done with it.
Problem with computer security is the people that actually really know about it (Hardware coders and hackers like Theo De Raadt, RMS, early IBM devs) is that like most modern scientists and experts they hardly ever weigh in their opinions on the matter assuming you already know the answer (or should), so you have to seek them out and ask them. Most comp scientists and pros are content to let you just fuck yourself over with bad security implementation, or are under NDA and more interested in selling you something and allow misinformation like using Virtual Machines as a security barrier to exist unchallenged. At least Theo De Raadt and RMS are telling people they're utter fools for using a VM for security. Nobody else is, although if you ask any developer they'll immediately tell you he's right from what I've been researching around IRC on dev channels. Sure these guys are abrasive complete neckbeard assholes, but it's their near religious conviction to freedom that makes them stand out from the legions of corporate drones and technocrats that typically infest the field of security.
I think Theo is right, the large corporate mass of security consultants are mainly con men who expertly fool people into thinking running 3 O/S's in a Virtual Machine is more secure than actually setting up 3 servers like you're supposed to so they can bid lower on contracts and keep most of the money for themselves. This is why Antisec, Anon, LulzSec, Carders and spammers have so much success is because of these con men fooling everybody into drinking snake oil.
Anybody here who wants a future after drug dealing pimpin (we can't do this forever lol) should do what I do, go through the MIT open courseware site and take all the comp sci + electrical engineering courses to learn python, security, signals, ect. Pirate all the ebooks you need, and pirate Absolute OpenBSD and every other relevant security book on nostarch press (or buy it, hey we're drug dealers we gots moniez) and install OpenBSD and learn it. It will pay off when nobody can catch you, and you'll learn something else so you can retire and use your criminal knowledge to secure something useful like your own bitcoin exchange site, your own silk road clone, whatever.
Being that we're all criminals we already have the balls to do whatever the fuck we want, might as well combine that with impeccable security methods to become unstoppable. How many white hats have you talked to that are more interested in filing into a corporation and scared to do anything 'illegal'. Certainly nobody here. I guess pkg_add anarchy instead of apt-get install anarchy busssaaaa
-
- if everyone is looking for the absolute perfect solution how far do you go..!?
- regular users are probably choosing the vmware solution for convenience and not because they work for the secret service.
- what is the practical solution..?!
- run a standalone solution if nobody trusts virtualisation software?!
-
like a chrooted Tor daemon
It is funny that you say this because virtualized solutions are widely recognized as more secure isolation than chroot. On most operating systems chroot ships with known jail breaking vulnerabilities. I hope you don't scare people away from using security enhancing solutions into using less secure solutions simply by quoting the opinion of one expert who just happens to be rabidly against almost any form of security that doesn't come from having absolutely perfect code. The fact that you suggest using chroot over using a paravirtualized system seems suspicious to me because it is widely thought that chroot is flawed and paravirtualized solutions offer stronger protection.
Also I am not certain if you can use chroot by itself to isolate firefox from external IP address, but I know you can use paravirtualization and full hardware virtualization to accomplish this goal. OpenBSD has a more secure version of chroot than most operating systems but it is even recognized that the OpenBSD version of chroot has inherent issues which are not present if you use paravirtualization or full hardware virtualization. I will wait for a detailed technical reply from Theo regarding the inherent security risks of using full hardware virtualization before I come to my final conclusion on the matter, but even if he talks poorly about paravirtualization (which avoids many of the issues he mentions when he talks specifically about the full hardware virtualization solution virtualbox, in the quotes you misconstrue as discussing virtualization based isolation in general) I will still be using it because I know it is a technique suggested by a number of very skilled security researchers, with Theo being (potentially) opposed to it but also not being the final authority regarding computer security.
For example, Qubes gains much of its security by automatically putting every launched application in an isolated virtualized environment, and FreeBSD ships with jails which also allow you to isolate applications with a layer of virtualization. Also Open Solaris has built in support for virtualization for security, Open Solaris Zones. Qubes, Jails and zones use virtualization that doesn't virtualize all of the hardware. Also Inferno uses virtual machines although I am not sure which type, I don't know much about inferno.
Again, I need to hear specific security risks from Theo before I come to my final conclusion on using full hardware virtualization, but right now I am leaning against it and towards using paravirtualization / OS virtualization solutions simply from what I have heard (from Theo, from other hackers who suggest not using Virtualbox or VMware due to code complexity and incorrectness of the hypervisor) and from what I have seen (Qubes, Open Solaris and FreeBSD use non-full hardware virtualization based isolation, although I am not sure if this is for security or for the other benefits it brings). I am still not convinced that it is actually a security risk to use full hardware virtualization systems, and I doubt I will ever be convinced against using virtualization based isolation at all.
vnconfig and virtual drives are essentially the same as using a VM for what we want (conceal your IP if anybody breaks in) except the difference is this virtual partition isn't being booted over buggy emulated hardware that hasn't been security audited whatsoever. vnconfig is integrated into OpenBSD and has been audited. Should an attacker breach tor somehow, they're now stuck on an encrypted virtual disk, on a separate partition in a chroot behind a firewall/NAT ect. so they'll only ever see internal IP addresses should they break out of chroot (which is incredibly easy to do.. chroot basically prevents applications from overloading mem and other problems, it's not really used for 'security' per se as anybody getting into a chroot can break out of it in a few easy steps according to these developers http://kerneltrap.org/Linux/Abusing_chroot)
Tor knows your real IP address so if they pwn Tor they have located you. If they can pwn Firefox they can configure it to go around Tor or use other techniques to determine your IP address, unless you take active measures against this happening. I don't think chrooting Firefox, by itself, can be used to prevent this. Explain in technical detail how to isolate an attacker who pwns firefox from being able to determine your external IP address by using vnconfig/chroot because I currently don't know how to do this. I will look over your solution and have some friends look it over as well. I am not saying it wont work, I just am not sure how to do it, or if it will work. I do know you can run Tor on a dedicated machine and firefox on another machine with only an internal IP address though, and I think this should be able to give isolation as well.
Yes chroot on most OS is easy to break out of but OpenBSD has a more secure version. However, most security people I talk with suggest using virtualization techniques for isolation over chroot because of how historically insecure chroot is.
After experimenting around with vnconfig making encrypted virtual disks and secure partitions I think I've managed to set up a pretty bulletproof tor session should the worst case scenario happen: NSA or Chineez government cracks/hax00rs tor, somehow the feds learn this method and use it to round us all up. Or worse my competitors find out this method and come after me :X
This indicates to me that you don't know what you are talking about, because it isn't Tor that you should be isolating so much as it is your network facing applications. If Tor itself is pwnt you are fucked no matter how many layers of isolation you are using.
and I can't believe I wasted so much time using X.
I can agree with this to an extent, I use command line for most things now. I only use command line for servers.
Loïc Duflot an expert in smashing out of X has basically said for a decade that X is not secure whatsoever no matter what tricks you do to isolate it.
X is insecure but there are various isolation tricks you can use. Qubes offers x isolation. You can also get your own x isolation by using virtualization. BTW OpenBSD with x windows is just as insecure as any other OS, if a single application is pwnt the attacker can EOP to root because there is NO GUI ISOLATION WITH X WINDOWS. The attacker can spy on ALL of your keystrokes and steal your password when you SU to root in a windowed terminal. This can be fixed by using virtualization. I wonder if Theo is aware of this.
Problem with computer security is the people that actually really know about it ....and allow misinformation like using Virtual Machines as a security barrier to exist unchallenged
This is cherry picking. There are numerous security experts who are strong advocates of using virtual machines for isolation. I am not certain if they would advocate the use of full hardware virtualization though (I will ask, and I also eagerly await some technical details from Theo explaining how full hardware virtualization is not only completely worthless but also horribly insecure), but I know the FreeBSD devs and the Qubes devs and the Open Solaris devs and the SEL4 devs are advocates of using virtualization for isolation. So are many other security experts. You have a biased opinion on virtualization based isolation if you are basing your opinion only on what the OpenBSD devs say. They are very against virtualization and imo seem to be against security via isolation in general, instead hoping that you use *only* code that has been audited by them for the past decade, because *only they* know how to write anything that isn't totally insecure shit.
At least Theo De Raadt and RMS are telling people they're utter fools for using a VM for security. Nobody else is, although if you ask any developer they'll immediately tell you he's right from what I've been researching around IRC on dev channels. Sure these guys are abrasive complete neckbeard assholes, but it's their near religious conviction to freedom that makes them stand out from the legions of corporate drones and technocrats that typically infest the field of security.
First of all things are not as cut and dry as you make them seem. There are numerous people who are widely recognized as security experts who advocate the use of virtualization based isolation. I may have fucked up by advocating for full hardware virtualization over / in addition to other sorts though, I need to do a little more research on this before I come to my final conclusion. Anyway, the three primary 'philosophies' of computer security are correctness, isolation and randomization. OpenBSD devs are religiously commited to security via correctness (although they do have very sophisticated randomization systems and have before pretty much anyone else, and they do have two tools for isolation but none of them use virtual machines or MACs) Others prefer security via isolation, knowing that only formally verified software is perfectly correct and that very very very little software has been formally verified, and that randomization can't protect from everything. It is a lie to say that any developer will immediately tell you Theo is right about this, many will immediately tell you that he is wrong actually. Most of the people who are big on security via isolation will tell you that he is wrong. Ask the Qubes devs or the FreeBSD devs or the Open Solaris devs or the SEL4 devs
I think Theo is right, the large corporate mass of security consultants are mainly con men who expertly fool people into thinking running 3 O/S's in a Virtual Machine is more secure than actually setting up 3 servers like you're supposed to so they can bid lower on contracts and keep most of the money for themselves. This is why Antisec, Anon, LulzSec, Carders and spammers have so much success is because of these con men fooling everybody into drinking snake oil.
I will concede that using full hardware virtualization MAY not be the best solution, it may be better to use other sorts of virtualization which will avoid all of the potential (although unsubstantiated and unexplained in technical detail) problems that you/Theo have brought up (well, IOMMU is also needed to fix some of them). I need to do more research before I conclusively say that full hardware virtualization should be abandoned in favor of using other sorts exclusively.
I personally am not convinced that you know what you are talking about and are not cleverly cherry picking opinions of certain people (none of which have yet said anything about anything other than full hardware virtualization, and I am not even sure I agree with his opinion on this yet I need to hear technical details and I need to talk with other security professionals including people who are fans of security via isolation) in an attempt to scare people away from more secure solutions. For one I don't think anyone other than maybe the OpenBSD devs would suggest using chroot for isolation over using jails for example. I will concede that you / Theo may be correct about the risks of full hardware virtualization though, I just need more time to research the matter. I also already know that the potential risks will not apply nearly as much if at all to other virtualized isolation solutions as they will to full hardware virtualization solutions.
Also I have heard from one hacker who I respect that breaking out of full hardware virtualization is actually more difficult than breaking out of other types of virtualization...I will ask him for his opinion on this issue as well. Essentially I need to do more research on this before I can make a more educated and conclusive reply to Theos comments on full hardware virtualization, but in short I am not sold on what he says and even if he turns out to be correct what he is talking about will apply much more strongly to full hardware virtualization than to other sorts.
edit: fixed technical error in what I wrote calling some systems that are not paravirtualization paravirtualization. Again, i am not an expert on virtualization and wish I had a few days worth of free time to read up on it in depth before I made a reply to this thread.
-
VMs allow for plausible deniability - I run TrueCrypt with a hidden volume on a VM, so it's a VM hidden in a VM.
-
So I talked with some computer security experts regarding this matter. I hold all of them in as high of regard as Theo, they are true experts . In general, they all seemed to agree with what Theo was saying about the inherent security issues related to using full hardware virtualization, however they did not in general come to the same conclusion as he did (that you are better off to not isolate firefox from external IP address than to use full hardware virtualization to do it).
The summary boils down to this: using full hardware virtualization does (very likely) have some security consequences, which could be significant or could be minor. I need to do more research to fully grasp the security implications of using full hardware virtualization, but the people I talked with have at least decent understandings of the issues. Many of the people I talked with suggested using full hardware virtualization to isolate network facing applications from Tor, saying that the security benefits this certainly brings will likely outweigh the security issues involved with full hardware virtualization. However, parvirtualization such as Xen offers the same isolation benefits as full hardware virtualization does, and it indeed does not have as much potential (probable?) security risk associated with it.
If the user is able to configure and use a paravirtualization system for isolation, they should use it instead of full hardware virtualization. Additionally, OS virtualization such as jails, zones etc offer much of the same isolation benefits without any of the risk associated with hardware virtualization (full hardware or paravirtualization). OS virtualization is probably easier for an attacker to break out of than hardware virtualization (either full or paravirtualization) but it avoids the risks that Theo is talking about with architecture virtualization security issues. Regarding my hacker friend who had previously told me that hardware virtualization offers stronger isolation, I misunderstood what he said because I didn't have a good enough understanding of virtualization when he was talking about it. Paravirtualization is also hardware virtualization, just not full hardware virtualization. full hardware virtualization probably is harder to break out of than OS virtualization, but paravirtualization is also probably harder to break out of and it greatly reduces potential security risks that are present with full hardware virtualization (due to the architecture issues that Theo was discussing).
These virtualization techniques can be layered, however using full hardware virtualization may not be a good idea if you are already using paravirtualization / os virtualization for isolation, because full hardware virtualization may have implementation flaws (including in the hardware that supports it) that could be used as an attack vector. This potential attack vector will not be present if you are not using full hardware virtualization.
So in short, if you can only be bothered to use the easy to configure full hardware virtualization solutions like Virtualbox, you should still use them to isolate network facing applications, instead of not isolating network facing applications at all. However, if you can configure the same thing using paravirtualization or OS virtualization you should use them instead and probably should avoid using full hardware virtualization as an additional layer. However, it is possible that using full hardware virtualization as an additional layer will add more security. It also may make you more insecure than only using OS virtualization or paravirtualization. However, attackers who can penetrate one layer of virtualization based isolation can likely penetrate other layers, using more than one layer may technically increase the 'depth' of the isolation but it will likely only be slowing an attacker down if they are capable of breaking out of isolation at all. Also, using full hardware virtualization may give attackers an additional vector that they otherwise would not have.
The general theme I saw was "many attackers can not break out of virtualized isolation, however the attackers who can break out of virtualized isolation can probably break out of as many layers of it as you use". And using full hardware virtualization does have potential/probable negative security implications that are not as much of an issue with paravirtualization and I don't think are issues at all with OS virtualization. But the risks of using full hardware virtualization do not out weigh the benefits of isolating Firefox from your external IP address, so if you don't plan to use anything else you should still be using full hardware virtualization based isolation . But there are safer ways to isolate Firefox from external IP address than using full hardware virtualization that should be used instead, if you have the skill to configure them.
Also, if you have enough extra machines it is probably more secure to use them to isolate firefox from the external IP address than to use a virtualization based solution. However, this doesn't mean you shouldn't use virtualization to do the same thing if you do not have extra machines or the skill required to isolate Firefox in this way.
here are some quotes:
"It is clear that you should try to keep network facing applications away from your external IP address"
"Using full hardware virtualization is better than not isolating Firefox, and it is much easier to configure than anything Theo would approve of"
"If they want to argue that full hardware virtualization is worse than not isolating Firefox away from your external IP address, ask them for an exploit that works against a full hardware virtualized system and not on an unisolated Firefox. They will not have one."
"Or ask for an easy to configure Theo approved solution for keeping Firefox isolated from the external IP address."
"One of the main things to keep in mind is that it is much easier to configure full hardware virtualization isolation than to configure any of the potentially better systems"
So there are some quotes from other people who are all security experts of the same caliber as Theo. Theo is also a security expert. They have different opinions. My personal feelings are that you should use paravirtualization or OS virtualization to isolate network facing applications from external IP address. If you can't be bothered to use paravirtualization or OS virtualization, you should still be using the easy to configure full hardware virtualization solutions. If you should use full hardware virtualization as an additional layer on top of OS virtualization or not is open for debate, it certainly has highly probable negative security implications, but it will also add an additional layer of isolation.
I hope that this helps to clear things up, or at least show another perspective on the issue. In the end nobody I talked with really disagreed with anything Theo said, they just think the risks of not isolating network facing applications from external IP address outweigh the risks of using full hardware virtualization to do so. Of course, they also all think that there are better solutions than using full hardware virtualization, they are just much more difficult to implement.
Another thing I would like to mention is that virtualization being used to isolate applications from external IP address has in practice prevented at least one hidden service from being traced after the feds pwnt it. I don't know the sort of virtualization that was used, but I think this is a clear example that there are serious benefits to using *some* sort of virtualization to isolate network facing applications from external IP address.
-
And now you've entered into the layered approach where *any error* in
the PC model exposed to the client operating system is not just a
crashing bug -- it is now exploitable.
Also nobody I talked with knew what he was talking about in regards to how all crashing bugs are exploitable if you use full hardware virtualization. Nobody claimed that this isn't true, but they all say that without technical details explaining the claim that they can not come to any conclusions regarding it. These are people who I think know enough about computer security that they would be aware of full hardware virtualization causing all crashing bugs to be exploitable if it was widely known in the computer security community. Theo really needs to substantiate this claim with technical details. Also, assuming this problem is related to mistakes in architecture virtualization, the risks will (very likely) be greatly reduced with paravirtualization and it shouldn't apply at all to OS virtualization.
If anyone has any questions or comments feel free to ask. I still need to do a lot more research on virtualization, everything I have said is correct to the best of my knowledge and I talked with numerous people who know their shit regarding security, but again I am personally not an expert regarding virtualization. I do know a thing or two about computer security though, and compared to corporate security people I am a boss imo ;).
In regards to all of the non-definitive terminology I am using (likely, probable, most likely, maybe, etc), a lot of the discussion is based on theory and a lot of the conclusions are based on probability (it is probable that a given full hardware virtualization has these security issues, although it may not be something that is inherent to full hardware virtualization. Also paravirtualization may have some of the same issues, but since a lot less is being virtualized it is likely that a given paravirtualization solution has a much higher degree of correctness than a given full hardware virtualization solution). For example, full hardware virtualization is much more complex than paravirtualization, so even if there are no currently known flaws in a given full hardware virtualization system or in the hardware that supports them, the potential for flaws is much higher simply because a lot more is taking place. I guess it is even possible that none of the issues Theo is talking about are true (maybe virtualbox did everything right!), it just isn't very probable at all. More academic level research needs to be done regarding many of these things before some of the claims can be definitive instead of just various degrees of 'probable', if that makes sense. Although it is generally accepted as true that complexity is roughly equal to insecurity. On the other hand, the people I talked with suggested that the added insecurity from the complexity of virtualization based isolation does not outweigh the added security of isolating network facing applications away from the external IP address, so in the end more things than simplicity need to be taken into consideration, although you should always use the least complex solution that allows you to acheive your stated goal (hence why paravirtualization is almost certainly better than full hardware virtualization, but full hardware virtualization is better than doing nothing at all).
-
Also can I please get a link to that thing about truecrypt not being secure in a virtual machine? I can not find anything about it anywhere. I think you may have misinterpreted something talking about hidden containers as being related to virtual machines.
Also I do not think you are a retard. I am glad to see people who know a thing or two about computers and security here. However, I disagree with your opinion, even though it is based on the opinion of a computer security expert. My opinion regarding virtualization is also based on the opinions of computer security experts. In the end you should do what you think is best. I think using *any* isolation to keep network facing applications away from the external IP address is a good idea, even if it means using full hardware virtualization. I also think you are going to be better off if you use paravirtualization or OS virtualization to accomplish the same goal.
Thank you for teaching me something new about computer security and giving me the information/motivation required to improve my security (because now I recognize that I should be using paravirtualization instead of full hardware...I never really thought of this before because I never realized full hardware virtualization had these security issues before, although I did recognize by myself that paravirtualization and OS virtualization would largely/totally avoid the security risks Theo/you pointed out to me, and I also got this realization confirmed by experts).
It is very rare for me to learn something new about computer security on underground forums these days. So good job you presented evidence and documented information / citations and you managed to increase my security and get me to suggest others increase their security as well. If we still disagree on the technique (virtualization) in general makes no difference to me, because I am still in support of it and now I know how to do it even better than before :) (even if you and Theo still think it is a technique only used by retards, at least I know several other expert level computer security people share my opinion as well!).
This is the type of debate I want to see on this forum. This is constructive. I don't want to argue with fucking retards who say you shouldn't use GPG, I want to argue with people who know what they are talking about and can help me to increase my security even if I disagree with their strategy / the conclusion they come to after examining the documented objective information related to the topic. When people come to different conclusions based on documented objective information, it is much better than when people make random shit up without even attempting to analyze/understand any material and talk out of their assholes.
-
Okay, I talked to someone else who is also a high level security expert. He is probably one of the most skilled security professionals that I know, actually. He doesn't want me to post logs of our conversation, but did say I can discuss the information that I learned from him. I will include a few quotes. One thing that is unrelated but which I would like to point out is that we had to agree to terminology prior to starting the real interesting conversation. For example, he calls sandboxing what I call OS virtualization. This is common in security circles, different people/groups use different terminology to describe the same things. This actually leads to a lot of confusion and inability to properly communicate, and I think it is something that the computer security community needs to work on fixing, with more standardized terminology.
Let me think of how to organize the information I learned. How about we start with a point by point list
A. The more code complexity a virtualization solution has, the more likely it is that an attacker can find a vulnerability that allows them to break out of the isolation.
B. Full hardware virtualization has the most complexity
C. Full hardware virtualization allows for more host OS access controls to be placed on the guests, for example they can be further isolated with mandatory access control systems to a greater extent than other virtualization solutions.
D. There is a distinction between breaking out of a hypervisor and breaking into the host. Although it is easier to break out of full hardware virtualization guests it can be made harder to break into the host OS if proper access controls are used on the host
E. One issue with full hardware virtualization is that it is a waste of resources and the greatly increased complexity leads to security issues, such as increased ease for an attacker trying to break out of the hypervisor
F. He thinks using paravirtualization is probably the best choice, if you use virtualization based isolation
G. He thinks using any virtualization based isolation is better than not isolating network facing applications from your external IP address
H. OS virtualization is immune to the sort of archetecture virtualization problems that Theo was discussing, paravirtualization is not at as much risk from them as full hardware virtualization is
I. He also suggests using OS virtualization over using full hardware virtualization, and seems to indicate that he actually had trouble picking between it and paravirtualization
J. Comparing these different sorts of virtualization in general terms (full hardware, paravirtualization, os virtualization) is not the best way to go about things, because a lot depends on the specific OS you are using, the specific virtualization product you are using, etc. Talking about things as generally as we are only allows for general comparisons to be made, at some point you need to compare specific solutions instead of types of virtualization, if you want to decide what the best choice for your task is.
K. FreeBSD has really good OS virtualization built into it (I love jaiils also)
L. The security of hardware assisted virtualization is dependent on the correctness of the virtualization hardware you are using (for example vt-d, this stuff is on your CPU if you have it btw)
M. In cases where para-virtualization requires API's to be added on a kernel level, a breakout could lead to direct kernel control. He suggests against using paravirtualization solutions that require additional kernel space API's
N. OS virtualization gives anyone who roots the virtualized OS direct view of the hosts kernel, and an attacker may be able to pwn the kernel from the guest.
O. OS virtualization is the least complex of the types discussed, potentially, although many solutions are probably over complex and shit.
P. Regardless of the type of virtualization used, nothing states that an attacker must first root or otherwise gain an account on the virtualized system before they can exploit the virtualization solution and get to the host. However, many potential ways of breaking through the isolation require the attacker to pwn the guest first.
Q. If you run an OS on hardware it is going to be a much more secure environment than virtualizing the same operating system. Virtualization decreases security of the virtualized operating environment in several ways as compared to running the environment on actual hardware.
R. In general / usually, full hardware virtualization causes the largest hit to guest OS security, followed by paravirtualization followed by OS virtualization. The hit to security correlates with the complexity of the virtualization solution, largely if not entirely because the correctness of the virtualization solution negatively correlates with its complexity.
S. Virtualization is more focused on cost reduction than security
T. The best possible solution is to run each network facing application on its own physical hardware and connect the different machines with a physical network while isolating applications from external IP address, while running Tor / Firewall / Intrusion detection systems on a dedicated machine as well and forcing all traffic to be routed via Tor. This is his number one suggestion.
U. Using full hardware virtualization will make it significantly easier for an attacker to pwn your guest OS (versus running it on hardware), but using full hardware virtualization to keep network facing applications away from external IP address will require an attacker to use more / more sophisticated attacks to trace you with a proxy by pass attack. He did ironically note that since you are significantly more vulnerable to having your guest OS pwnt (versus running it on hardware) that this will remove some of the protection from being traced: yes an attacker will likely need to pwn the VM then break out of it and into the host OS to get your external IP address (although they don't need to have an account on the guest to break out of the hypervisor and into the host OS). However, he pointed out that since you are more likely to have your (guest) OS pwnt in the first place that this may end up reducing the previously mentioned added protection against traces.
and now let's wrap it up with a list of techniques and how he rated (or apparently rated, to me) them
1. Physical hardware isolation, with Tor on one machine, Firefox on another isolated from external IP address (strong number 1)
2. Paravirtualization based isolation
3. OS virtualization based isolation
4. Full hardware virtualization based isolation
5. No isolation
I think if you take advantage of the ability to further isolate a full hardware virtualization guest OS with mandatory access control systems, he might bump it up the list. One of the main benefits of full hardware virtualization is the ability to isolate it additionally on the host OS, so that even if an attacker breaks out of the hypervisor they can't break into the host OS. It is harder to gain this protection from break INs to the host OS by using paravirtualization or OS virtualization solutions (however it is harder to break OUT of paravirtualization or OS virtualization in the first place 0_0).
Also I think in reality he would want to know specific details, specific goals, specific software programs used, operating system used, configuration details, etc before he made a list of 'best' to 'worst'
-
It is important to note that these conversations specifically related to the security benefits of virtualization in regards to isolating applications from the external IP address. If you take other attack scenarios into account, such as an attacker pwning your firefox VM and spying on your messages when you decrypt them (assuming you decrypt messages in the same VM you have firefox on) using full hardware virtualization may actually be an overall hit to security. Yes, it will likely make you significantly harder to trace via hacking / proxy by pass attacks, but if the attacker will have a significantly easier time to pwn the guest OS (versus it being on hardware) it may not matter if they can not trace you on the appication layer if they can spy on all of your plaintexts and communicate them back to themselves via the Tor network.
When I take this scenario into account, I actually am forced to change my opinion to as follows:
1. If you use full hardware virtualization you shouldn't decrypt messages on a VM that has internet access at any point in time after you have sensitive info (plaintexts, passphrases, etc) on it
2. Failing this, you should not use full hardware virtualization and should instead use nothing (although if you want to use something you should use either paravirtualization, OS virtualization or best of all physical hardware isolation)
It should also be noted that you can probably use snapshots / cloned virtual machines to make only decrypting messages / writing plaintexts / entering key passphrases on VMs that have no internet access after / before (context dependent) they are used a lot less complicated than it sounds.
Oh yeah one more thing about virtualization solutions, if you are using guest addons and sharing folders with the host etc you are compromising your own isolation, all of that shit should not be enabled
-
Hmm interesting, OpenBSD and FreeBSD devs writing correct code is the basis of all security. If you are using binary blobs to manipulate hardware (many linux drivers do this) then you are basically hoping that there's no bugs/overflows that can be exploited because you can't see the vendors source, so hope for the best. If the code is correct from the beginning then it enhances security. This is why OpenBSD has a notoriously slow and methodical approach to coding so they get it right the first time. They also have a very different mechanism for updating CVS whereas the Debian project has thousands of part-time developers around the world all contributing with no standards (according to BSD devs).
Take for instance the Debian dev in 2006 who commented out two lines of code to get rid of some strange errors he was seeing. What he didn't know is that he commented out crucial random number generating code and in effect, reduced all keys generated on Debian machines (and all their clones) to 15 bit entropy. !! It wasn't discovered until 2008. For 2 years anybody could have MITM attacked any openSSL connection and ripped root/super user passwords easily. Anybody could have decrypted the id_rsa key in a couple of minutes and just logged straight in.
Linux kernel development itself is also questionable, since Alan Cox and the rest of the super bug finding coders have all left due to Linus Torvalds.
Add on top of all that questionable fast release code from Xen/Virtualbox since it's primary function is testing and investigation of error prone software and not security and you have bugs stacked on top of bugs. OpenBSD's mantra is the simpler your setup is, the more secure. The more packages and pf filter rules you have the more you're decreasing security. I think it's pointless to jail or virtualize any X browser if you need maximum security when you can use lynx or w3m. A vendor certainly wouldn't need firefox to post here or log into silkroad tho I haven't tried the main site with lynx but I suspect it works fine. A bitcoin trader could just use their bot and lynx to trade securely.
What I meant by Tor exploit was the possibility of a buffer overflow (like the one patched in Dec) so isolating Tor behind a firewall/dmz and using it as a private bridge is a must if extreme anonymity is required which that guy you quoted agreed as physically separating applications under traditional dmz and vlan rules is best. You can use OBSD redundant failover firewalls using CARP + Pfsense and NAT to isolate Tor (jailed/chrooted) in the DMZ, running intrusion detection where it only ever sees internal addresses, so unlikely priv escalation on the Tor box would amount to much unless the attack wget their own Tor malware with built in snoopwares and install it without you knowing which is likely if you follow that guy's .onion guide where he recommends running Tor as root in an Virtualbox instance.
I guess the simple rule is the more packages and software you run, the more chances of exploits. If running a minimalist OBSD/FBSD network segregated into firewall/dmz/vlan this should increase security exponentially. Ditching X all together and using a text based browser to do business further reduces exploits.
On not using Truecrypt in a VM this comes from Bruce Schneier's attacks on TC containers. Let's say you spawn a virtual Debian instance, plug in your TC encrypted USB key and decrypt it. Your priv keys and data are leaked all over that VM and now you are trusting buggy virtual machines to safeguard this data which was shown by him to be leaked using a variety of word processors, gmail/google docs and other programs while the TC container was opened. The VM can also leak to Dom0 through a hundred different methods, which won't matter if your primary host o/s is already full disk encrypted but if it's not forensics can recover data or malicious exploits in DomU can. Full disk should be mandatory. TC patched a lot of these problems but his team described it as the 'tip of the iceberg' meaning if him and a bunch of other cryptographers got together and did this on a regular basis who knows how many holes they'd discover. This is primarily why I encrypt twice. First encrypt really sensitive data with LUKS or softraid then wrap it in TC deniable containers just in case Truecrypt development isn't up to par and a major exploit is found (while I'm sitting in jail and their working on my servers).
While this forum was down I read a shit ton of ebooks on BSD network security and leased myself a 1U failover rack firewall running OpenBSD for $31/mth, set up an internal DMZ/NAT firewall with a $40 comp, placed Tor by itself on a minimal openbsd installation chrooted with console only access on an old SPARCserver I had lying around from 1999 (runs awesome!) and am testing Tails live CD with it as a bridge for persistence to avoid it grabbing guard nodes everytime I reboot. Mainly because I'm interested in plausible deniability as well as security (if Tails turns out not to fail). I like the idea of removing the disk, wiping memory and having an O/S that's never been touched by biz the feds in my country won't find anything on though I could always symbolic link all logs/.bash.history and everything else to /dev/null. I'm also testing a custom OpenBSD .iso I modified instead of having to rely on linux and burn yet another new debian security update for Tails every couple of weeks. As for my now ridiculous rack stack and no doubt sudden surge in power consumptionI can always claim my private bridge is for research for democracy activists, which it sort of is with some other projects I have. Though I'm leaning towards only using lynx/w3m browser from now on and command line gpg. Less software I install and have to trust while doing this kind of work the better.
Ask your security friend what forum software he recommends. I'm leaning towards custom SMF or even some sort of perl implementation if I can avoid PHP all together. Now I'm going to attack my network to see what kind of data leaks
-
VMs will make you sick from paranoia, use Liberte Linux it has everything you need. Kernel hardened, storage encrypted, TOR configured and runs just fine on most computers. Installation very simple from windows, use windows formatted FAT32 pen drive run setup.bat - done. simple and very functional.
-
VMs will make you sick from paranoia, use Liberte Linux it has everything you need. Kernel hardened, storage encrypted, TOR configured and runs just fine on most computers. Installation very simple from windows, use windows formatted FAT32 pen drive run setup.bat - done. simple and very functional.
Does Liberte use a 32 bit OS? If it does you are not getting the advantages from ASLR since 32 bit ASLR can be brute forced. I also don't know if they have implemented mandatory access control profiles even though I know they have the ability to do so with hardened Gentoo. At least they use persistent entry guards, unlike Amnesia. What I am trying to say about Liberte is that even though they are using a good base OS (hardened gentoo) that has a lot of security features, I am not sure if you are actually getting the advantages it offers with Liberte because many of the security features have requirements and I am not sure if Liberte meets them (64 bit? preconfigured MAC? etc). Also Liberte has no isolation of the browser from external IP address and pretty much everyone I talk with about security agrees that it is pretty vital for some isolation mechanism to be used. If you don't isolate firefox from your external IP address your anonymity hinges on firefox not having any exploitable remote code execution vulnerabilities, I personally know that I don't want my entire anonymity to hinge on that.
By the way, running Liberte or Amnesia in a full hardware virtualization environment is going to make them less secure just as much as running OpenBSD or anything else in such a VM.
Really if you are using a windowed environment without isolation ALL of your security hinges on NONE of your applications having remote code execution vulnerabilities because the x window system and all other mainstream window systems have no isolation, if a single windowed application is pwnt the attacker can spy on all keystrokes sent to all windows. This means after any of your windowed applications are pwnt the attacker can spy on your password when you SU to root and then they can EOP to root. This is true with Windows OS as well. Graphical desktop environments themselves are insecure (although not inherently). If you run the X window system on OpenBSD you are just ask weak to this attack. Isolation protects from this, it protects you from being traced if one of your network facing applications is pwnt, there are two *huge* security benefits that I personally would like to have. When Theo is talking about OpenBSD and suggesting against isolation he is probably assuming that you are using CLI only and operating a server, ask him about his opinion on the lack of isolation in X and the EOP to root attack I just mentioned. He will probably reply saying that you should be using CLI only.
I don't know what is more important to me, the isolation of firefox from external IP address and protection from known EOP attacks or the significantly enhanced OS security that comes from not using full hardware virtualization. But I do know that I would rather take a minor hit to my OS security and get the previously mentioned major security advantages, than not use isolation at all. And I know that I can achieve this with paravirtualization or OS virtualization. I could also take *no* hit to my OS security and get the same advantages by using isolation on the physical layer.
-
Hmm interesting, OpenBSD and FreeBSD devs writing correct code is the basis of all security.
Although I like both FreeBSD and OpenBSD it is insane to think that they are the basis of all security. One thing I don't like about FreeBSD is the fact that it entirely lacks ASLR. It does have one of the most awesome mandatory access control systems I have ever seen though. It also has a really good OS virtualization tool, Jails. I don't like that OpenBSD has almost no support at all for virtualization technology, because I like to isolate my network facing applications from external IP address. I could use OpenBSD on hardware and make a Tor router though, and isolate Firefox by running it on different hardware and only letting the machine it runs on have access to an internal IP address. I will probably be doing this, and I think OpenBSD is a great choice for OS in this scenario. I also don't like the fact that OpenBSD entirely lacks a mandatory access control system. This seems to piss off a substantial number of security professionals actually, although the OpenBSD devs/fanboys argue against the use of mandatory access controls as well.
I have heard the following from one security professional: 'Hardened Gentoo can certainly be used for the configuration of a more secure environment than can be obtained by using OpenBSD, however OpenBSD is more secure out of the box and the proper configuration of Hardened Gentoo is an extremely difficult and time consuming task'. I also personally think that Hardened Gentoo is the way to go if you want the best possible security and have the time and skill to configure it.
If you are using binary blobs to manipulate hardware (many linux drivers do this) then you are basically hoping that there's no bugs/overflows that can be exploited because you can't see the vendors source, so hope for the best. If the code is correct from the beginning then it enhances security. This is why OpenBSD has a notoriously slow and methodical approach to coding so they get it right the first time. They also have a very different mechanism for updating CVS whereas the Debian project has thousands of part-time developers around the world all contributing with no standards (according to BSD devs).
I agree that non-open source software should be avoided. I don't see the link between code being correct from the beginning and code being open source though. However code being open source may very well lead to it being more correct over time. It also lets you check it yourself for correctness, which is a big benefit but also requires that you know how to audit code. I think they are right about Debian.
Take for instance the Debian dev in 2006 who commented out two lines of code to get rid of some strange errors he was seeing. What he didn't know is that he commented out crucial random number generating code and in effect, reduced all keys generated on Debian machines (and all their clones) to 15 bit entropy. !! It wasn't discovered until 2008. For 2 years anybody could have MITM attacked any openSSL connection and ripped root/super user passwords easily. Anybody could have decrypted the id_rsa key in a couple of minutes and just logged straight in.
Yes I knew about that Debian vulnerability
Add on top of all that questionable fast release code from Xen/Virtualbox since it's primary function is testing and investigation of error prone software and not security and you have bugs stacked on top of bugs.
Xen being used for isolation/security has been established as something that expert level security researchers suggest, for example the Qubes operating system (and other expert level security people I talked with about it, all of whom said paravirtualization is the best option for virtualized isolation and all of whom said that paravirtualization based isolation is better than no isolation at all and significantly less insecure than full hardware virtualization)
OpenBSD's mantra is the simpler your setup is, the more secure.
OpenBSD's mantra is the more correct your setup is, the more secure. This is recognized as fact by everyone. However, you need to take your threat model into account when you decide on the level of complexity required to acheive it. Not using GPG presents you with an environment that has less code complexity, does that mean that you should stop using GPG and that in doing so are you increasing your security? Of course not. The security advantages that some code brings outweighs the increased risk that comes from the added complexity. For me (and everyone I talked with) the advantages of isolating applications from external IP address and avoiding windowing system EOP to root vulnerabilities outweigh the disadvantages of increased complexity, *even if the least secure sort of virtualization is used* (however I don't think they took attackers stealing plaintexts into account when they weighed in on full hardware virtualization, so I think you should use OS or paravirtualization or nothing, if you don't want to use physical layer isolation)
The more packages and pf filter rules you have the more you're decreasing security. I think it's pointless to jail or virtualize any X browser if you need maximum security when you can use lynx or w3m. A vendor certainly wouldn't need firefox to post here or log into silkroad tho I haven't tried the main site with lynx but I suspect it works fine. A bitcoin trader could just use their bot and lynx to trade securely.
I don't know if I would agree that additional pf filter rules decrease security, although you should probably be using the least amount required to achieve your goal. Is lynx even maintained anymore? I have thought of going full CLI before, I might look into it again.
For me isolation is a requirement. I will probably start using physical layer isolation since it gives the benefits I am looking for and has no security disadvantages. If not I will probably use paravirtualization or OS virtualization. I wont be using full hardward virtualization anymore though, including for live CD's. I certainly wont stop using isolation though, the very important security benefits it brings are far too great for me to stop using the technique at all.
What I meant by Tor exploit was the possibility of a buffer overflow (like the one patched in Dec)
If you use a 64 bit version of OpenBSD you are essentially fully protected from all buffer overflow attacks via ASLR. You will get the same benefit on any other 64 bit OS that has implemented full ASLR (and you will get some of the benefit if the OS has implemented partial ASLR).
so isolating Tor behind a firewall/dmz and using it as a private bridge is a must if extreme anonymity is required which that guy you quoted agreed as physically separating applications under traditional dmz and vlan rules is best. You can use OBSD redundant failover firewalls using CARP + Pfsense and NAT to isolate Tor (jailed/chrooted) in the DMZ, running intrusion detection where it only ever sees internal addresses, so unlikely priv escalation on the Tor box would amount to much unless the attack wget their own Tor malware with built in snoopwares and install it without you knowing which is likely if you follow that guy's .onion guide where he recommends running Tor as root in an Virtualbox instance.
There is little point in running Tor in a chroot or jail since if it is pwnt the attacker can get your IP address even if it is isolated. The only thing it will do is make it harder for the attacker to root the host OS on the machine Tor is being run on, but if you make a Tor router machine and Tor is the only thing you are running on it other than the OS etc there is little point to this. I will probably make a tutorial for physically isolating Tor using a dedicated OpenBSD machine in a few weeks, if you want to make it first feel free and I will make a tutorial on how to use paravirtualization and OS virtualization for people who don't have extra machines and for people who use laptops from random locations. You are right that we need to ditch full hardware virtualization and move to more secure solutions ASAP though.
I guess the simple rule is the more packages and software you run, the more chances of exploits. If running a minimalist OBSD/FBSD network segregated into firewall/dmz/vlan this should increase security exponentially. Ditching X all together and using a text based browser to do business further reduces exploits.
I think I already did a good job of explaining the trade offs between complexity and features. In some cases added features are worth added complexity. You should always aim to use as little code as required to achieve your goals. My goal is isolation of network facing applications from external IP address (and my secondary goal is isolation of windowed applications to protect from EOP to root attacks). The software based solution for accomplishing this with the least code is OS virtualization. Paravirtualization also achieves this with much less code complexity than full hardware virtualization, and also comes with its own security advantages/disadvantages as compared to OS virtualization. If you use physical isolation you can acheive this goal with no added code complexity, so this is clearly the route to go. However, it doesn't mean that it is the *only* route to go, and it doesn't mean that you shouldn't get these security advantages in other ways if you can't use physical layer isolation for whatever reason.
On not using Truecrypt in a VM this comes from Bruce Schneier's attacks on TC containers. Let's say you spawn a virtual Debian instance, plug in your TC encrypted USB key and decrypt it. Your priv keys and data are leaked all over that VM and now you are trusting buggy virtual machines to safeguard this data which was shown by him to be leaked using a variety of word processors, gmail/google docs and other programs while the TC container was opened. The VM can also leak to Dom0 through a hundred different methods, which won't matter if your primary host o/s is already full disk encrypted but if it's not forensics can recover data or malicious exploits in DomU can. Full disk should be mandatory.
Can I get a link to the article please? Anyway I will keep trying to find it. What you are saying may very well be true although I am not sure if a key is anymore likely to leak in a VM than it is on a normal OS. Not using FDE is opening yourself up to forensic teams finding your private key if it ever leaks from RAM, and there are multiple ways this could happen even if you are not using a virtual machine. If using a virtual machine increases the risk of key leaking or not is something that I do not know, and I would love to read about it. FDE should be mandatory. So should keeping your laptop on you at all times. FDE isn't going to protect you from anything but attackers who don't know you are using it or don't know shit about attacking more sophisticated targets. Is your computer by a glass window that faces outside? They will use a laser microphone to keylog you from a distance based on analysis of the sounds you make when you type. Or they will analyze fluctuations in the power grid. Or they will sneak in and use a hardware keylogger. Or they will rush in when they raid you, flash freeze your RAM, put it into a forensics laptop and dump your key. Or they will use hidden cameras. Or they will add a software keylogger to your bootloader. Or they will do one of a dozen other things to steal your encryption key.
Memory in encapsulation material
Shielded equipment and not plugged into the electrical grid to protect from transient electromagnetic pulse analysis
physical tripwire systems that cause an immediate shutdown to memory wipe
physical surveillance and intrusion detection systems to watch for intruders
keeping your machine on you at all times
a lot of additional steps go into getting much benefit from FDE, assuming that the attacker knows you are using FDE and know the (many) methods to counter it via stealing passphrases / keys. Of course most LE still power down machines during raids.
TC patched a lot of these problems but his team described it as the 'tip of the iceberg' meaning if him and a bunch of other cryptographers got together and did this on a regular basis who knows how many holes they'd discover. This is primarily why I encrypt twice. First encrypt really sensitive data with LUKS or softraid then wrap it in TC deniable containers just in case Truecrypt development isn't up to par and a major exploit is found (while I'm sitting in jail and their working on my servers).
Using two layers of encryption for file storage is the suggested practice. You should use FDE and then additionally you should encrypt your sensitive files (preferably one at a time, although less compartmentalization is still a benefit and requires you to remember substantially less passwords).
While this forum was down I read a shit ton of ebooks on BSD network security and leased myself a 1U failover rack firewall running OpenBSD for $31/mth, set up an internal DMZ/NAT firewall with a $40 comp, placed Tor by itself on a minimal openbsd installation chrooted with console only access on an old SPARCserver I had lying around from 1999 (runs awesome!) and am testing Tails live CD with it as a bridge for persistence to avoid it grabbing guard nodes everytime I reboot.
Cool
Mainly because I'm interested in plausible deniability as well as security (if Tails turns out not to fail).
I wouldn't put much faith in Tails turning out to be anything other than fail, personally.
I like the idea of removing the disk, wiping memory and having an O/S that's never been touched by biz the feds in my country won't find anything on though I could always symbolic link all logs/.bash.history and everything else to /dev/null. I'm also testing a custom OpenBSD .iso I modified instead of having to rely on linux and burn yet another new debian security update for Tails every couple of weeks. As for my now ridiculous rack stack and no doubt sudden surge in power consumptionI can always claim my private bridge is for research for democracy activists, which it sort of is with some other projects I have. Though I'm leaning towards only using lynx/w3m browser from now on and command line gpg. Less software I install and have to trust while doing this kind of work the better.
I am also considering going full CLI and ditching GUI's for good. I think it is almost a requirement for true security. You can still use virtualization without a GUI btw, one person I talk with was shocked that you don't need a GUI to use virtualization lol.
Ask your security friend what forum software he recommends. I'm leaning towards custom SMF or even some sort of perl implementation if I can avoid PHP all together. Now I'm going to attack my network to see what kind of data leaks
He would probably suggest Frost or Syndie. Frost is tied to Freenet. Syndie can be used on a number of anonymity networks but it was made by the I2P crew. Syndie actually lets you host a single forum environment over several sorts of anonymity network / server / newsgroups / etc. I have done only a little research on either of these systems, I personally much prefer Tor to Freenet or I2P and think it offers substantially better anonymity than either of those options. I personally like PunBB for a minimalist and secure php forum. Some people are working on programming a decentralized forum in Ruby right now, would you like to join us?
-
Please forgive this uber noob question, but what is the point in setting up a Virtual Machine, they can't make your connection any more secure/anonymous can they?
My understanding was they gave you the ability to wipe your machine (but keep all progs) in like 2 minutes, am I missing something?
I mean I guess you could wipe your machine after closing TOR each time, so if any fucker has gotten some virus to you while you were online... is that it?
Please someone bring me up to speed here, thanks! ;D
VMS are great for test running .exe files.
-
I thought this thread has some good infos so i wanted to put my .02BTC and ask some questions.
h4xxtheplanet, I see the appeal of BSD, its so simple that you can understand it, but It does not have some of the SELinux MAC features. I agree console only would be the way to go for high security, but i need X. Are you still console only?
Has anyone heard of TrustedBSD?
I didn't see any mention of using a USB boot device to compare checksums of the files on you internal HDD.
Does anyone have experience recompiling the kernel in a static way such that loadable modules are disabled? please PM
Custom SELinux policy for sandboxing and NATing the tor browse bundle?