Comments

Guy • April 18, 2017 6:22 AM

Isn’t this just yet another in a long list of ways to exfil data? Doesn’t a lot need to go wrong before it’s impactful?

Winter • April 18, 2017 6:54 AM

I remember articles from the very start of VM’s stating in no uncertain terms that VM’s are not secure and should not be used as if they were securely separated from each other.

So this does not come as a surprise.

Winter • April 18, 2017 7:07 AM

No surprise, but still an impressive achievement.
As our host likes to say: Attacks only get better over time.

wiredog • April 18, 2017 7:09 AM

Huh. I thought that was obvious. I set up VMs so that they can communicate via shared folders just to make it easier to keep data synchronized where necessary. Heck, VMWare makes it easy to do that while setting up a VM.

Who? • April 18, 2017 7:44 AM

@ wiredog,

No, it was not obvious. Data exfiltration happens through a CPU cache covert channel.

keiner • April 18, 2017 7:51 AM

VM is nonsense in terms of security. Get physical. And separate hardware as good as possible…

Winter • April 18, 2017 9:12 AM

This is a burgeoning field. I found these blasts from the past:

Attack of the week: Cross-VM side-channel attacks
https://blog.cryptographyengineering.com/2012/10/27/attack-of-week-cross-vm-timing-attacks/

Wait a minute! A fast, Cross-VM attack on AES
https://eprint.iacr.org/2014/435.pdf

EXPLOITING PROCESSOR SIDE CHANNELS TO ENABLE CROSS VM MALICIOUS CODE EXECUTION
https://www.blackhat.com/docs/us-15/materials/us-15-DAntoine-Exploiting-Out-Of-Order-Execution-For-Covert-Cross-VM-Communication-wp.pdf

However, the study referred in the original post is not about a side-channel, but about a full blown encrypted communication channel.

John Galt • April 18, 2017 11:11 AM

@ Schneier

VMBR

Virtual Machine Based Rootkits

Almost as nasty as a Microcode Based Rootkit.

Paid for by the public dole (psychopath black budget) and a little help from others. Probably from the same budget line item that pays artists to create crucifixes in a jar of urine.

Source code included.

http://web.eecs.umich.edu/~pmchen/papers/king06.pdf

http://windowsitpro.com/security/virtual-machine-based-rootkits

We thank the anonymous reviewers and our shep-
herd, Steve Gribble, for suggestions that helped us im-
prove this paper. We thank Peter Biddle, Brandon
Baker, and Eric Traut for providing valuable insight
and discussions about this topic. We would also like to
thank Rick Rashid, Ted Wobber, Butler Lampson, and
Paul Barham for providing feedback on early versions
of this paper. This research was supported in part by
National Science Foundation grants CCR-0098229 and
CCR-0219085, by ARDA grant NBCHC030104, by In-
tel Corporation, and by Microsoft

Buck McFly • April 18, 2017 11:35 AM

Credit where it is due: https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Etienne-Martineau-Inter-VM-Data-Exfiltration.pdf:

“””
At the end of this talk we will go over a working VM to VM reverse shell example as well as some surprising bandwidth measurement results. We will also cover the detection aspect and the potential countermeasure to defeat such a communication channel. The source code is going to be release at that time on ‘github’
“””

The talk is here: https://www.youtube.com/watch?v=7X772EBdvnM

Ross Snider • April 18, 2017 2:07 PM

@Winter

The last paper doesn’t seem to achieve remote code execution (I was hoping to see this) but instead a series of covert channel leakage (of keys, etc).

This isn’t to take away from the paper, just it’s misleading title. These attacks are incredibly neat, for sure, and in many cases have practical implications.

Also, pretty interesting paper won the NSA’s best security paper some years ago: an effective mitigation to many of these VM attacks is to shuffle the VMs around so that they are not co-resident with other VMs for too long! Pretty surprising and fairly easy to implement, as well as being easy to characterize in terms of performance costs.

Dirk Praet • April 18, 2017 2:23 PM

@ wiredog

I set up VMs so that they can communicate via shared folders just to make it easier to keep data synchronized where necessary.

Doesn’t everbody? I’ve got an entire pool of VMs that (on demand) share both local and cloud storage with their host either over hgfs or sshfs. No separate (Dropbox-OneDrive-Google Drive-whatever) clients needed on the guest OS’es, which is especially practical for unsupported platforms.

The 45KBps covert channel these guys are talking about – even an SSH connection! – is something entirely different and not particularly good news for folks hosting their entire infrastructure in the cloud.

@ Ross Snider

… an effective mitigation to many of these VM attacks is to shuffle the VMs around so that they are not co-resident with other VMs for too long!

Yes and no. If the ‘evil’ VM is moved around too it can attack others. I would be kinda interested in how to detect such an attack. So would most devops, I suppose.

Clive Robinson • April 18, 2017 6:50 PM

I guess it needs to be said that,

    Researchers build a covert channel between two virtual machines using a shared cache.

That this is by no means a new idea, just another instance of a cache covert channel.

Which is a sub-class of the more general class of “shared resource side channel” communications.

To do this all you need is a shared resource and an ability to measure it in some way. For instance some years ago it was shown that the temprature inside a computer fractionaly changed the frequency of the crystal that controled it. Thus if the host was “dual-homed” or had multiple VM’s on it by measuring the network timing you could show that two network interfaces or to VMs shared the same crystal. Thus things like Honeynets could be found or an insecure service running on the same host as a much more secure service that is being targeted.

I’m mentioning this not to detract from the researchers work, but to make people aware of just how difficult it is to avoid being open to this class of attack.

Chris Abbott • April 19, 2017 12:47 AM

I use Virtualbox (was just on my VMs connecting to my SSH/SFTP server a minute before I read this ironically). I usually disable use host I/O cache and have a different host and guest OS (I know this is CPU cache, but maybe it helps a bit security wise). I bet things can get through the drag and drop feature too.

GregW • April 19, 2017 7:31 AM

So, could one create a covert channel between two physical hosts if they shared the same network switch?

Clive Robinson • April 19, 2017 7:58 AM

@ GregW,

So, could one create a covert channel between two physical hosts if they shared the same network switch?

Providing a host has a way to measure the behaviour ot the switch then the answer is yes.

The only other question to ask is what the bandwidth would be?

As this paper has demonstrated, it may well be much higher than you would at first suspect.

Welcome to the world of covert channels by shared resources.

Oh and before people ask, I can see a way to do it via a shared UPS if it’s the online type.

Put simply most UPSs of that type like mechanical generators change the waveform they generate under load, some even the frequency. If you examine the way most audio inputs work on PCs these days they have insufficient analog components to remove “mains hum” caused by circulating currents in the PSU. Instead they use DSP tricks to remove the hum. If the audio chip can be accessed then the likely hood is that the filtering could be either turned off or changed in some way to make measurements much easier… To send data all the computer has to do is change it’s computing load which makes the load on the UPS rise.

I’ll leave it upto some students in an Israeli University to do the rest, as they have before.

confused • April 19, 2017 8:20 AM

I’m confused about how this is useful. Who’s doing the communication? If it’s between two VMs you control, why not go on the network? If one of the parties is malware on an infected VM, wouldn’t this make you very noisy and detectable? Or can this be hidden effectively from the host VM OS?

Mike • April 20, 2017 12:04 PM

Is this supposed to be news? Nearly any shared resource can be used for a covert channel. If you don’t like having a covert channel, don’t share; otherwise, make a business risk decision.

My Info • April 20, 2017 12:12 PM

@Mike & Ike

Is this supposed to be news? Nearly any shared resource can be used for a covert channel. If you don’t like having a covert channel, don’t share; otherwise, make a business risk decision.

Think about checksums like CRC-32 that were designed to protect against the risk of “accident,” vs. one-way hashes like MD5, SHA1, SHA2, etc. that were designed to protect against the risk of murder.

Risk of arson isn’t the same thing as risk of accidental fire.

Clive Robinson • April 20, 2017 1:29 PM

@ Mike,

If you don’t like having a covert channel, don’t share; otherwise, make a business risk decision.

Oh if onky they would… But they don’t, msnagment make a decision based on the CapEx they will let you have, and if you not they are lucky then the organisation won’t get attacked before you find another slightly more reasonable managment to work for…

The thing is managment are generaly in it for the short term to boost “shareholder value” then like the rats they are jump ship before it sinks. They talk up what a success they were, and if the organisation carries on looking good they will claim it’s because of the good foundations they put in place. If however it goes t1ts up they claim that those that followed them were not upto following their initial good lead…

With mentalities like that they win you lose unless you are more fleet of foot than they are…

Thus it’s like the old joke about two friends in the woods being chased by a bear. When one stops to tie his boot lace the other says “you’ll never out run the bear like that!”. The lace tier replies “I don’t have to out run the bear, only you”.

So make sure your laces are well tied at all times and out run the rats.

Clive Robinson • April 20, 2017 1:53 PM

@ My Info,

Think about checksums like CRC-32 that were designed to protect against the risk of “accident,”

Aghh, no that’s not what they were designed for. They were designed to detect errors caused by AWGN in an analog Shannon Channel, after the digital signal had been recovered (demodulated). If the noise sepctrum is not AWGN then they are less effective for a whole heap of reasons. AWGN whilst being random has the same energy/hz bandwidth whilst Pink Noise has the same energy per octave increase in frequency (in electronics this is known as “flicker noise”).

Patriot COMSEC • April 20, 2017 8:44 PM

Counter-intuitive, highly complex attacks such as this are not going to stop. This example shows how state actors have the advantage in exploiting and nurturing weakened systems for collection.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.