3

I was looking at a question asking about Dual booting in SuperUser, and I was if there is added protection of using a VM over dual booting. From what I've been told, a VM is it's own sandbox, and that everything that happens (or almost everything) will only affect the VM.

Now, lets say you have 2 HDs, or even 1 HD that is dual booted. Is there the same security sandbox in place at all? I would assume that 2 HDs, would be safer than 1, just in case the Malware is able to spread over the sinlge HD, and could this also might be the same for a VM?

So my questions are.

  1. Is there any security advantages over using a VM vs just dual booting?

  2. Will using the same HD for your Dual Boot/VM cause more security risks due to being on the same HD as your regular boot?

I am assuming that advanced malware, that could attack hardware, would play an issue here, which is why I assume that the same HD could be an issue. Would it be possible for Malware to infect another HD that is a separate boot?

EDIT: It seems that VM is the way to go, which is funny because it seems like a Dual Boot is more work to set up, while being less secure.

To add to another part to the question, are there certain VMs that are much more secure than others, or are they all pretty much the same? One point was saying that some VM use their own kernal, while others will use the Systems, so that seems to be the first step...

But is there anything else we should look for when finding a VM? I know someone who uses VMWare currently, but not sure how good that one is..

Thanks a lot all!

XaolingBao
  • 897
  • 2
  • 9
  • 21

5 Answers5

8

If you plan to run malware or at least untrusted binaries, then I would recommend running it in VM (or even segmented hardware).

You can't trust what the "dirty" system is doing with other partitions, boot sectors, or BIOS, when it is booted.

Additional advantage is that most of virtualization software can provide you with some kind of snapshots. You can the use the snapshots as:

  1. take a snapshot
  2. run untrusted software / malware
  3. revert the system state to trusted state before running malware

It should be noted that even running in Virtual Machine is not 100% safe of problems. Time to time, ways of how to escape the sandbox of the virtual machine are found. For example CVE-2014-0983

grochmal
  • 5,677
  • 2
  • 19
  • 30
Michal Ambroz
  • 311
  • 1
  • 5
0

In addition to what @Michal Ambroz said, it would be very wise to not only run in a VM, but also in a VM that does not directly use the parent system kernel or have access to modify said kernel. KVM-based virtualization provides this type of environment as it allows for the virtual machine to use its own kernel.

The overall security advantage is that a virtual machine compartmentalizes the software being run into its own environment which will in most cases prevent the software in the VM from accessing the parent server.

Dual booting on the other hand, involves separate partitions, but does not prevent them from accessing each other and modifying files.

  • In the first paragraph, I believe that you're comparing full virtualisation with something like docker. Pretty much all virtualisation methods allow for the VM to run its own kernel (Xen has that PCI passthrough that allows for hardware access by the guest but those are still two kernels). The situation of several VMs using the same kernel is docker, but docker containers are not really called VMs. – grochmal Oct 23 '16 at 04:06
  • Thanks for the info both of you, much appreciated. @grochmal so that means that Any VM should keep me safe, or are there recommended ones that one should look at? From Michal Ambroz's answer, it seems you could still bypass the VM, so is there something more to how this happened even though the VM is running it's own Kernel? – XaolingBao Oct 23 '16 at 04:38
  • @XaolingBao - Not using a computer is the only thing that keeps you safe from malware. You can bypass everything. It is just that bypassing a VM is much, much, harder than bypassing a dual boot (in the dual boot there is almost nothing to bypass to be fair). – grochmal Oct 23 '16 at 22:28
  • @grochmal well... Yeah we can be super protective and make sure we have no computers or devices that could cause us issues, but that's not the point of what we are trying to accomplish. Thanks for the info about VM's though. – XaolingBao Oct 25 '16 at 17:41
0

if by 'dual boot' you mean one OS per HDD, with one HDD unplugged: that is closer to an air gap, which could be more secure than a VM. however, as the other answerer suggests, each OS would have access to the BIOS, which could be dangerous.

if by 'dual boot' you mean two OSs on the same HDD: that is definitely less secure than separate hard drives. imagine both OSs were fully encrypted on one HDD - the bad OS could upload the full encrypted contents to a web server, and then overwrite that good OS with an equivalent looking bootloader that prompts for the encryption password, which is then uploaded to the web server. so then an attacker would have both your encrypted full OS and the encryption password, without ever having run an executable on the OS you were trying to protect.

as for VMs i don't know as much !

infinite-etcetera
  • 760
  • 1
  • 5
  • 10
  • 1
    One OS per hard drive is not air gap. To get somewhat close to airgap, you've got to physically disconnect the hard disk that's not in use. Even then you're still vulnerable to firmware based attacks. – Lie Ryan Oct 24 '16 at 13:48
  • @LieRyan yes i meant physically disconnected, but i didn't explicitly say that, true. i'll edit that for clarification. – infinite-etcetera Oct 24 '16 at 14:40
  • Nice answer, but what is an "air gap?" (assuming it's a technical term). So essentially you would have to disconnect the other HDD from use before using it? Wouldn't you fully Disconnect it from hardware all together. @LieRyan are you saying the firmware attack would happen after you plugged it in, because how would it get affected if it's unplugged fully? Thanks. – XaolingBao Oct 25 '16 at 17:39
  • an 'air gapped computer' basically means a computer that is in no way connected to the internet, and can even mean no connection to other computers. for example in nuclear power stations, for security reasons. – infinite-etcetera Oct 25 '16 at 18:37
0

This is a great question:

In my opinion there are few reasons to use Dual Boot over VM. The biggest issue with Virtual Machines are attempting to run malware samples that have capabilities to check for specific hardware settings in your device before running. For example:

 Checks for BIOS
 Checks for CD Drive

Side note: And, in some cases they check for specific movements from your cursor to make sure you're human. Which Malware engines such as hybrid-analsyis have countermeasures for.

If the malware doesn't detect both of those it will not run, as a sort of VM detection. But there are ways around this!

On to security reasons:

I usually do Malware Analysis dynamically, so I like to have a remnux client, and another Windows client. This way I could run fakeDNS on remnux and set the DNS for my windows machine as the remnux IP, while running wireshark on it. This gives me robust network analysis capabilities. Here is a good guide for that:

https://countuponsecurity.com/2015/01/13/dynamic-malware-analysis-with-remnux-v5-part-1/

Additionally, as originally said by Michal Ambroz, it's extremely important to be able to take snapshots. Not only just to revert your machine to a clean state, but analysis can take preparation, and I like to save snap shots at certain stages during my analysis.

Your greatest concern, when using the setup from above are two options are; finding a way to have SAFE internet access and secondly, VM detection from Malware and how to prevent it.If you are running this lab from your home, I would recommend buying a cheap secondary internet as a precaution.

Badlarry
  • 136
  • 4
0

You have 3 scenarios:

Dual Boot

If you have only one HDD drive or you have different drives for each OS but you don't disconnect the unused ones, then a compromised OS can access the data in the partitions of the other OSs. Say OS A is compromised, then an attacker can mount partition from OS B, modify the OS B and compromise it too (Remember that protection over files is given only by the running OS, as OS A doesn't have to protect files from OS B the attacker can change them)

To protect against this you could encrypt both volumes so an attacker can't mount the other OS partition, but the attacker may be able to damage it anyway

If you have one HDD drive per OS and you physically disconnect the unneeded ones, then an attacker needs some kind of firmware malware to go from OS A to OS B. This is extremely unlikely, not only cause firmware malware are very rare and difficult to develop, additionally the attacker should previously know information about OS B in order to develop a firmware malware that can successfuly compromise it


Virtual Machines

Here the attacker has two approaches posible: Guest into host or host into guest

Guest into host: If your guest OS gets compromised it will give you somekind of sandbox. The guest OS shouldn't know about the host OS neither the underlying hardware, but keep in mind that systems like VMware or VirtualBox are not security focused, those are made for convenience and therefore exists some ways to go around its sandbox and gain control over the host OS, to do this the attacker should be high-skilled (Assuming you're not using a known vulnerable virtualization software version)

Host into guest: In this case the attacker can control your host OS and modify the files used by the virtualization program, the virtualized disk directly or even use the virtualization program as you would. Guest is also compromised if host is


Hypervisors Type 1

You didn't mention it but I think that is something that should be metioned. In your question you talk about virtualization, the most used way to virtualize OSs is using software like VMware or VirtualBox that runs on a host OS and virtualizes the resources taken from it to be used by a guest OS. In this case the resources managed by host OS are given to the virtualization software (a.k.a. hypervisor) which manages them for the guest OS which manages them for the applications running on it

There is other type of hypervisors that run directly over the hardware and segments it to run multiple OSs over it. In images it's this:

enter image description here

In this case OSs should be completely isolated. OS A knows nothing about OS B and can't access its virtualized hardware. There are some known vulnerabilities that may allow an attacker to escape the sandbox of the hypervisor to corrupt memory on the other OSs, but to do that in order to compromise OS B from OS A an attacker should be high-skilled and have knowledge of your setup and the current state of the memory in OS B to properly modify it without just crashing it

Mr. E
  • 1,954
  • 9
  • 18