virtualbox.org

mpack wrote:

Armando wrote: A program, however, can actually be launched by another one (virus or malware)

Circular argument. Where did that first program come from? It didn't appear by magic, it appeared because basic rules were not followed, as already said.

I understand your point and your definition of "circular argument".
I just wanted to say that, being malware engineers quite clever and mainly focused just on bypassing "basic precautions" (and also non-basic ones), a malware CAN sadly "appear" even when basic rules are followed. It is surely quite less likely, but we can not take safety for granted just because we follow "basic rules" (which are also, by the way, quite subjective). That would be wonderful, but it's not real. :]

ChipMcK wrote:

socratis wrote:This could also be a good use for snapshots. You make a snapshot that you know is clean, you test the malware, you revert to the basic image. Never happened.

First reasonable use of snapshots I ever read; otherwise, not of much use.

Well, another quite "reasonable use" could be related to any kind of test you'd like to perform in a VM: installing or removing something, changing some sensitive or complex configuration, letting OS updates "affect" the guest and so on.
In short: whenever you think a quick way to "get back" could be useful. :]

I agree with mpack in saying that when the test involves any possible security risks it could be better to work on a (independent, full and obviously "sealed") clone of the VM, so that the original VM remains absolutely untouched.

mpack wrote:I do not trust VirtualBox to undo changes made to add a snapshot to the VM.

Why? Is that a gut feeling or do you have evidence that a snapshot is not rolling back all changes? I regularly test malware in an isolated box (no LAN, no internet, communication via one read-only shared folder) and I have so far believed that rolling back a snapshot (there is only one, the whole setup is as simple as possible) gets rid of whatever the malware might have done.

jonha wrote: have so far believed that rolling back a snapshot (there is only one, the whole setup is as simple as possible) gets rid of whatever the malware might have done.

It does. Mpack's distrust of snapshots comes from years of experience of having users misunderstanding what snapshots are, how they work and a) believing that they are backups, b) overusing it (I've once seen a VM with about 140 convoluted snapshots).

Having said that, I always take a snapshot on my VMs (around 30 of them) and I always test things on a "clean" environment. If I want to make a permanent change (like a Service Pack or Windows updates), I create a second snapshot (empty) and I merge the base and the first snapshot. Never had a single problem in the last 5 years, doing it approximately once a month for around 30 VMs.

socratis wrote:

jonha wrote: have so far believed that rolling back a snapshot (there is only one, the whole setup is as simple as possible) gets rid of whatever the malware might have done.

It does. Mpack's distrust of snapshots comes from years of experience of having users misunderstanding what snapshots are, how they work and a) believing that they are backups, b) overusing it (I've once seen a VM with about 140 convoluted snapshots).

Well, in that case, the wording of mpack's statement was somewhere between unfortunate and misleading. The fact that some users regularly misuse powerful tools* in no way reflects on the usefulness of said tools in the hands of users who know what they are doing (as mpack in all probability does).

* Alas, the more powerful a tool, the easier it is to misuse it. I can't count the number of times I was asked by friends or co-workers to debug their regexes or to explain why they didn't work. I am sometimes cursing the guy who invented them

jonha wrote:Well, in that case, the wording of mpack's statement was somewhere between unfortunate and misleading

In what case? Socratis gave you a guess, an incorrect one as it happens.

My position is based on simple logic: any snapshot operation has a small but non-zero probability of failing, leaving you with a dead VM. Don't believe me? Look it up.

Cloning the original VM, on the other hand, does have a zero probability of damaging the VM. That's it, in a nutshell. It isn't rocket science.

mpack wrote:Socratis gave you a guess, an incorrect one as it happens.

Hey, I tried my best, based on (misunderstood from my part maybe) past comments . Of course I should have added ", but only Don can tell you for sure.", which is what you did. Thanks.

mpack wrote:any snapshot operation has a small but non-zero probability of failing

OK, unless I missed something, here's how it goes: base VDI + empty snapshot, a ~2.1 MB file (2097152 bytes to be exact) filled mostly with zeroes, except the header part with UUID, parent UUID, size, type, etc. Nothing vital. If you work with your VM from that point on, the snapshot file gets modified and your base VDI remains untouched.

Something with a non-zero probability happens to the snapshot file/chain. I can think of a couple of things:

1. Power outage, HD corruption, etc, that affects the snapshot file.
2. You're done (looking at your malware) and you want to revert back to base VDI + empty snapshot. Things go wrong at the VirtualBox or OS level.

Am I missing something? Because the whole time that you're working with a snapshot that you're going to throw away in any case, your base VDI remains untouched. If things go wrong, well, fine. Delete the snapshot references from the "VM.vbox" (personal preference) or from the VirtualBox Manager, start VirtualBox (with your base VDI only now), create a new empty snapshot, done. Back as we were.

mpack wrote:My position is based on simple logic: any snapshot operation has a small but non-zero probability of failing, leaving you with a dead VM. Don't believe me? Look it up.

I see. As I see it, that is more on the "gut feeling" end of the spectrum. I have current backups of all my VMs, so even if such an operation goes haywire, it'd not be a disaster.

mpack wrote:Cloning the original VM, on the other hand, does have a zero probability of damaging the VM.

Nothing to do with hardware or software has a probability of zero. But this is moving into transcendental territory. I think I know what I need to know re your position.

jonha wrote:Nothing to do with hardware or software has a probability of zero.

Please leave such specious sophistry at the door. Yes, God and a choir of angels could appear and smite your PC, but the cloning operation itself has ZERO probability of damaging the original VM, because only read operations are performed.

Exhibit A, we have a method that involves zero risk of data loss. Exhibit B entails a small risk. Therefore I prefer exhibit A. I fail to see any "gut feeling" involved in this position.

In the past this problem was more serious because it was effectively impossible to backup a VM if it used snapshots. Nowadays people always make backups right? So the only risk is of being inconvenienced, but that risk is still enough for me to continue what I see as a best practice.

The snapshot/test is a good idea - thanks. But the universal use of javascript nowadays makes this less practical. A cross-site script can install linux things, no?

A thing which bothers me would be, maybe, rootkit class of objects? (I'm no expert) I know a trend is for attack codes to be written which try to minimize their apparent activity. Installing themselves somewhere and then activating later. Even if tested in a guest OS, how would you know without a daily deep-analysis (like a checksum of every file) of the guest OS? I guess this equates to, "how do you know testing is complete?"

About shared folders: how about a shared "throwaway" SDcard?

socratis wrote:The point I was trying to make is that a virus can run in the VM and can affect any file in the host, if there are read-write shared folders or read-write network shares.

@Armando: You got it right

Armando wrote:as long as a VM is "sealed" (no usb drives connected, non writable shared folders or LAN drives...), no harm can be done outside the VM by any software running inside the VM.

I'll just add one more advice if you're going to be using your VM for testing malware; since you're going to be accessing the internet (either Bridged or NAT) make sure that you follow proper firewall and antivirus protection rules on your host, because the VM still has network access to your host (they're on the same subnet) and could be attacking by other means.

I would suggest if you download potential malware, but before testing it, to disconnect your VM from the network altogether. The cable connected Yes/No would be the easiest way to do this.

This could also be a good use for snapshots. You make a snapshot that you know is clean, you test the malware, you revert to the basic image. Never happened.

rpmurray wrote:I have read that some malware disguised as innocuous programs will test to see if it's in a VM and if it determines that is the case does not install it's malicious bits. So testing software on a VM is not always a guarantee that it is clean or safe to move it to the host.

Wouldn't this be an argument to do *all* your work in a VM (running on a linux host)? I know that wastes precious CPU cycles, but machines are tres fast nowadays. I've started doing this, and simply shutdown the VM and running DejaDup on the host to backup the VM. I suppose one would want multiple backups in case something with a delayed start was installed. Secret data exfiltration malware is a separate problem I'm not sure how to handle.

On a side note, if you run your web-facing servers in a VM, would that make problems of the following type go away?
https://krebsonsecurity.com/2017/01/ext ... more-37597

pattimichelle wrote:The snapshot/test is a good idea - thanks. But the universal use of javascript nowadays makes this less practical. A cross-site script can install linux things, no?

This has absolutely nothing to do with the discussion in the thread so far. A cross-site script can infect your computer (virtual or not) if you choose to open a web page in your host from a malicious website running on your VM. That would definitely break the rule of complete isolation that was mentioned and is the basis of this thread.

pattimichelle wrote:rootkit class of objects?

And? A clone or reverting to previous snapshot would solve it, as it was already mentioned. Attacking the VirtualBox BIOS or EFI? Could be, in theory, but what does an attack on a virtual BIOS gains? In that theoretical (I repeat) case, a clone would be more than adequate, even for the most paranoid out there...

pattimichelle wrote:Even if tested in a guest OS, how would you know without a daily deep-analysis (like a checksum of every file) of the guest OS? I guess this equates to, "how do you know testing is complete?"

This thread (and this forum for that matter) is NOT about doing virus analysis. You would get much, much better answers if you were to search in antivirus sites, which make heavy use of VMs as well.

pattimichelle wrote:About shared folders: how about a shared "throwaway" SDcard?

You could have a throwaway anything. If you want to make it appear as (or it actually is) an SDcard, sure, why not?

pattimichelle wrote:Wouldn't this be an argument to do *all* your work in a VM (running on a linux host)?

Not a universal advice I'm afraid. Here's a real-life example...

I translated VirtualBox in Greek with the help of a guy from another city in Greece. We've become friends since then. Running VMs is all he does. He's having a few Linux boxes that do nothing else but hold his different VMs. So much so, that for Xmas he sent me his two unused, high-end GPUs. So that my daughter can play her new favorite game (mine was too old). Which she couldn't do in a VM. So, no, your advice is not universal. It varies and depends on a case by case basis...

Thanks for this information. Yep, I was aware that some graphics stuff won't work in VB (I haven't tried other VM's). I guess for those game computers (etc.) you would want dedicated hardware.

Hmm. I didn't notice this back in May.

rpmurray wrote: I have read that some malware disguised as innocuous programs will test to see if it's in a VM and if it determines that is the case does not install it's malicious bits. So testing software on a VM is not always a guarantee that it is clean or safe to move it to the host.

It's a reasonable scenario, but I've never encountered it. I think its easy to spot suspect software, just like it's easy to spot suspect emails, so in that case the software would never leave the VM, and all the normal precautions apply (don't leave executables in shared folders).

My rules for trusting an app are that I know and trust whomever produced that app, and that I got it direct from them. I might still have been caught by that Sony rootkit from a few years back, but I can't think of any other instances. Part of trusting the source is understanding their business model: if you know that their income stream would be ruined by the suggestion that they source malware, then they don't source malware. Adware - maybe.

I wouldn't think to speak of behalf of rpmurray, but I suspect where his thinking might come from; malware analysis. I believe that he wasn't talking about your typical "Your Flash is outdated!" (you get adware installed) kid scripting, type of malware. I think that he's talking about the really hardcore Trojan/rootkit/Cryptolocker/Ransomware that is smart enough to hide itself when the analysis when inside a VM, but unloads its payload when in an actual computer.

One of the reasons I personally try "suspicious" links on throwaway VMs is exactly that.