Jump to content

opening spam mail docs in vm

Hey people,

 

i´ve always liked spam mails. They tend to have a hidden beauty inbetween the lines and realy "good" spam mail are being moved into a "nice spam" folder.

 

Now sometimes i want to open their attachments but i am not stupid doing this on my windows pc.

I know VMs are capsuled from your pc and you can do crazy stuff there without harming your pc.

Am i safe opening spam attachments in an virtualbox VM?

Am i unsafe if i connect it to the web?

 

I don´t want to risk anything and i am pretty adept on computer stuff so maybe someone of you did this before and can give me some tips?

 

Thanks

Link to comment
Share on other sites

Link to post
Share on other sites

I mean don't open it if its a security risk in the first place. But if you have to, A vm will get rid of most of the risk. Also some browsers do this automatically, with each tab almost acting as its own vm.

Link to comment
Share on other sites

Link to post
Share on other sites

2 minutes ago, Electronics Wizardy said:

Also some browsers do this automatically, with each tab almost acting as its own vm. 

Nice to know.
Nah i would never open spam attachments on my day-to-day operating system. I´m also thinking about setting up a decoupled "spam" pc, but i think a vm is somehow the same thing.
Just want to get sure that nothing can break out.

Link to comment
Share on other sites

Link to post
Share on other sites

27 minutes ago, Lukle said:

Am i safe opening spam attachments in an virtualbox VM?

More or less, it should be self contained in the VM. But you still shouldn't do risky things on a PC you care about.

27 minutes ago, Lukle said:

Am i unsafe if i connect it to the web?

If you connect to a network and the attachment is malware that tries to spread over it, it's possible that it's unsafe. However, it can only attack things that it has unfettered access to. A lot of things are blocked by default, but there are a few other things, namely like attaching a USB external drive to a router, that are left wide open for convenience.

Link to comment
Share on other sites

Link to post
Share on other sites

You could always keep an "air-gapped" network and computer for sketchy files. There's also operating systems such as Qubes that will can create secure "containers" that you determine to help with pretty much exactly what you want to accomplish.

 

Never heard of it until I saw a previous post a hour or so ago, so I've done a little digging and it's a pretty interesting system. https://www.qubes-os.org/intro/

Link to comment
Share on other sites

Link to post
Share on other sites

giphy.gif

 

There are, therefore, two possible at-risk areas:

  1. The actions the host takes in response to a VM exit. If there are any bugs in this handling it may be possible to persuade the host to execute something it shouldn't.
  2. Any host access to the guest machine's memory space. Remember the host machine code running in ring 0 can waltz in and crash the party wherever it so pleases. It just so happens that you can set the guest's memory from the guest (surprisingly).

This leads you to your exploit mechanism. You need a handling bug in the VM exit routine, then you need to be able to persuade that code to execute some memory, ideally code you just put into a page from the guest vm. Once done, say bye to Kansas.

As Tom Leek says, VMs are incredibly effective in defending against fork bombs. In a similar vein to the way the OS can limit how much memory a process can allocate, so it can limit how much memory is mapped to the VM. Run out and the guest OS believes it is out of physical memory; the host will not allocate it more unless you implement a VM exit to do this, which would be a bit dangerous and I do not believe this is done.

How likely is this?

Not very. It depends on those VM exit implementations entirely, or reading memory from the guest on the host with a nice bug in your reading code. It also requires that said bug would allow you to control the crash in such a way that you can force execution to the memory address your host holds. The VM exit must be able to access that memory.

What I have not covered?

  1. Attacks on existing software stacks such as TCPIP. The vulnerabilities here are the same as if you had two actual phsyical PCs anyway.
  2. Entirely software implemented virtualisation.
  3. Virtualisation on any other type of chip. This applies to Intel VT compatible setups.

There is no enemy. The foe on the battlefield is merely the manifestation of that which we must overcome. The doubt, and fear, and despair. Every battle is fought within. Conquer the battlefield that lies inside you, and the enemy disappears like the illusion it is.

Link to comment
Share on other sites

Link to post
Share on other sites

Their are appliances or SaaS like FortiSandbox which do that.

For you the easiest way would be to enable Hyper-V on your machine, set up a VM with Windows 10, create a snapshot and after you are done with your poking around apply that snapshot.

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×