Bitdefender Finds 'Hypervisor Wiretap' For Reading TLS-Encrypted Communications (helpnetsecurity.com)

Orome1 quotes a report from HelpNetSecurity: Bitdefender has discovered that encrypted communications can be decrypted in real-time using a technique that has virtually zero footprint and is invisible to anyone except extremely careful security auditors. The technique, dubbed TeLeScope, has been developed for research purposes and proves that a third-party can eavesdrop on communications encrypted with the Transport Layer Security (TLS) protocol between an end-user and a virtualized instance of a server.
Bitdefender says the new technique "works to detect the creation of TLS session keys in memory as the virtual machine is running." According to HelpNetSecurity, this vulnerability "makes it possible for a malicious cloud provider, or one pressured into giving access to three-letter agencies, to recover the TLS keys used to encrypt every communication session between virtualized servers and customers. CIOs who are outsourcing their virtualized infrastructure to a third-party vendor should assume that all of the information flowing between the business and its customers has been decrypted and read for an undetermined amount of time."

Comments

How. Does. It. WORK.

[Anonymous Coward]

Guise, I'm really not interested in your breathless teasers.

Give me the rundown. How does it work? You know, the abstract, the overview, the quick so-and-so is what we did to make it work. If it's not in the summary then you're not doing your job. If it's not in the linked article, then you're just wasting my time. If it them might possibly maybe with a lot of luck be in a video of a conference that hasn't even been published yet, you're just taking the piss. I am not amused.

WHERE ARE THE DETAILS?

Re: How. Does. It. WORK.

[Anonymous Coward]

Yeah it does. Up until 2013 the FIPS implementation guide from NIST contained language that explicitly singled out any implementation of crypto on virtualized machines as insecure. It is gone now, but still has a deeply vailed language to that effect. If you are on virtual, only acceptable for of crypto is external HSM, but... With memory access you are toast anyway. It is not a coincidence that Thales developed technology that allows you to run applications inside the secure boundaries of the HSM (circa end of 2012)

Also, any CPU with ... Cough... Management Engine ... Cough... Can do the same (read your keys, and data in clear text)

Re:How. Does. It. WORK.

[Anonymous Coward]

"Guise"??

http://www.dictionary.com/brow...

Um, what?

Re:How. Does. It. WORK.

[Dunbal]

Umm wrong dictionary. L2 internet.

Re: How. Does. It. WORK.

[Bruce Perens]

The host reads the virtual guest's memory and process state. This is absolutely no surprise, it was always implicit in virtualization systems.

Re: How. Does. It. WORK.

[Anonymous Coward]

Any proof that anyone other than the owner of the PC can enable and use ME?
Any proof that anyone with access to ME can access memory?

References please.

Re: How. Does. It. WORK.

[Anonymous Coward]

No doubt, why is this even news? Why bother get the keys too. With access to the guest VM memory, you can see the messages after decrypting.

Re: How. Does. It. WORK.

[Anonymous Coward]

Intel Active Management Technology - Known vulnerabilities and exploits. There's quite a bit of Q35 chipset hardware floating around in the field. Research continues, of course. -PCP

Re: How. Does. It. WORK.

[dbIII]

It's a surprise to all those people who thought virtual machines would provide some sort of security by obscurity, which is probably just about every "cloud" customer out there unfortunately.
One of the emulation programs, I think it was Bochs, used to give a warning on each startup not to depend on VMs for security.

Re: How. Does. It. WORK.

[Bruce Perens]

In other words, businesses that did not have a systems programmer or didn't listen to one. My customers are often embedded systems companies and often they have no idea how people can look inside their systems. One stripped their executable symbol tables to keep them from scrutiny. I showed them how the evil hacker tool "strings" would reveal their hidden menus :-)

Re: How. Does. It. WORK.

[K. S. Kyosuke]

Isn't this what the SMM has always been about? That's been around since...I don't know, 80386?

Re:How. Does. It. WORK.

[arglebargle_xiv]

Give me the rundown. How does it work?

Two-sentence summary: You run your crypto and store your keys on a computer controlled by your opponent. Quelle surprise, this turns out to be insecure.

Re:How. Does. It. WORK.

[cwsumner]

... Where are the Details?

It's all Classified! 8-P

P.S. How come you could use all caps, but I got an error?

This isn't a big deal, it's fucking huge.

[Anonymous Coward]

TLS is in just about everything and if they can unwind that realtime, they can no doubt unwind some other encryption implementations sitting on top. #No_more_secrets.

Re:This isn't a big deal, it's fucking huge.

[Sax Russell 5449D29A]

Well, this is a virtual machine they're eavesdropping on. Anyone running something on a virtual machine should always assume that the one controlling the underlying hardware can always see everything that's happening on the VMs too. My view has always been that if I don't have the physical hardware before my eyes, I have no real guarantee someone isn't tampering with it either legally or illegally. Heck, even if it's before my eyes, someone may still have tampered with it at some point in time, or even remotely.

Re:This isn't a big deal, it's fucking huge.

[Attila Dimedici]

Yes, it is a big deal. But the key thing here is that the summary implies that this only works from the hypervisor to unwind encryption on a virtual machine which it is hosting. What this means is that the "cloud" is inherently insecure and that it cannot be secured. Something I have suspected since the "cloud" first became a thing.

Re:This isn't a big deal, it's fucking huge.

[Anonymous Coward]

Not to mention the hypervisor has access to the VMs file system, and thus the private key.

The only thing to gain by extracting the private key from memory instead of the file system, is that often the VM needs to be either taken down or suspended to gain access to the file system.

But seeing as the hypervisors host system needs to occasionally be taken offline for maintenance anyway, its pretty trivial to cause a situation where the VMs migrations/reboots are delayed in a normal standard excusable way.

Re:This isn't a big deal, it's fucking huge.

[Sarten-X]

What this means is that the "cloud" is inherently insecure and that it cannot be secured. Something I have suspected since the "cloud" first became a thing.

What it really means is that IT managers need to do their jobs.

A "cloud" isn't inherently insecure any more than it's inherently insecure to host your own servers, or to have them colocated at a datacenter, or to pay an outsourced company to just handle all the computer stuff. They all have their risks, and those risks must be understood and considered before you start implementing any solutions.

It is extraordinarily lazy to simply discard an option with the excuse that "it cannot be secured", when what you really should be saying is that "it cannot be secured to meet my acceptable level of risk using the techniques of which I am aware". The latter description highlights the resolution to your problem: Do some research and learn about the risks and mitigation techniques available to you. Cloud providers, for instance, will usually be quite happy to enter contracts promising that they'll protect your data from illegal release, and providing adequate recourse if they don't. Datacenters will often provide isolated space for your servers, with access restricted to only certain personnel, or even only your own employees. A cheap outsourced service provider may not provide any assurances of privacy... but you might not even need any such protection for your company's archive of already-released press releases.

In IT, this is your job. You must be aware of the risks inherent in every solution, and understand how they can be avoided, mitigated, or accepted. This analysis must happen not just for hosting consideration, but for every choice. Do you block a certain website in your firewall, or ban a particular application? How will the users respond? Will they be likely to work around the restriction in a riskier way? Will the new policy impact the business in a positive or negative way?

Know all of your options, and list all of your assets. Gather all of the information you can before you have to make a decision. That's the only way to improve your security.

Re: This isn't a big deal, it's fucking huge.

[Anonymous Coward]

We live in the post Snowden world. Pretending its some sort of acceptable 'risk' when its clear 5 eyes countries have been datamining our comms and business secrets is to simply ignore what we already know. Cloud is backdoored. American and British kit is backdoored. Their satellites backdoored, their routers backdoored, its all shite kit.

The solution is to keep your servers in your control, so that your business secrets and customer secrets remain yours.

Re:This isn't a big deal, it's fucking huge.

[JonathanP.Bennett]

Well, this is a virtual machine they're eavesdropping on. Anyone running something on a virtual machine should always assume that the one controlling the underlying hardware can always see everything that's happening on the VMs too. My view has always been that if I don't have the physical hardware before my eyes, I have no real guarantee someone isn't tampering with it either legally or illegally. Heck, even if it's before my eyes, someone may still have tampered with it at some point in time, or even remotely.

Exactly this. If you don't control the bare metal, then the VM isn't fully trustworthy. Even before the details of the attack were worked out, this should have been an obvious conclusion.

Re:This isn't a big deal, it's fucking huge.

[Anonymous Coward]

It's trivial to take a filesystem snapshot, mount and extract whatever files.

Or just extract it from the backup which is typically done by the hosting company.

Re:This isn't a big deal, it's fucking huge.

[Gr8Apes]

A "cloud" isn't inherently insecure any more than it's inherently insecure to host your own servers, or to have them colocated at a datacenter, or to pay an outsourced company to just handle all the computer stuff. ...

Know all of your options, and list all of your assets. Gather all of the information you can before you have to make a decision. That's the only way to improve your security.

The cloud is inherently insecure. Anytime you place all the parts needed for encryption outside your control, amazingly, it is no longer in your control. See any non-connected DRM for a long list of failures.

That said, the only cloud based services that can be "secured" are storage and communications if you externally encrypted the data. Externally means that the only thing the cloud service sees is an encrypted file or stream. There is no ability to decrypt that storage, no keys are associated with it, no algorithm is even evident on the service. Best yet, any number of current web services will suffice for this, including Google, MS, and DropBox. You can checkout OTR (Pidgin/Adium) and PGP plugins for a good idea of how these work and how to really secure your services. I predict that such approaches will happen sooner than later, as more and more problems with "it's the cloud" and other outsourcing options crop up.

Re: This isn't a big deal, it's fucking huge.

[Sarten-X]

Oh, no! As a financial institution, the government might get my customers' financial data! You know, that same data that we send to the IRS every year...

It doesn't matter what your data is or who you want to protect it from. You always need to do a critical risk analysis, and make conscious decisions about the cost of paranoia and the impact to your business. Just because a celebrity fugitive says that the government can read your data does not mean that you actually have a security problem.

Re: This isn't a big deal, it's fucking huge.

[Anonymous Coward]

Oh, no! As a financial institution, the government might get my customers' financial data! You know, that same data that we send to the IRS every year...

(1) I very much doubt you send EVERYTHING to the IRS every year, detailing all transactions, all logins, all mistyped passwords, etc. (2) If "the cloud" means your financial data is being stored on Russian, US, Chinese, and/or Iranian servers, it very well means potentially divulging your data to a lot more than "[just] the IRS" which would be the expectation of most people in the US.

It doesn't matter what your data is or who you want to protect it from. You always need to do a critical risk analysis, and make conscious decisions about the cost of paranoia and the impact to your business.

No doubt. The real problem is that a lot of your statements like "Cloud providers, for instance, will usually be quite happy to enter contracts promising that they'll protect your data from illegal release, and providing adequate recourse if they don't." become absurdly meaningless if, say, in China it's legal to look through foreign financial records. Ie, critical risk analysis has to be actual critical and not just hand wave away whole areas of discussion with blank terms like "illegal release". Hell, given that there's been a consistent problem with people suing the NSA because of a lack of standing because of an inability to prove what is almost certainly "illegal release", even when used in a meaningful sense it can still be quite meaningless.

Just because a celebrity fugitive says that the government can read your data does not mean that you actually have a security problem.

No, but "a celebrity fugitive" has brought to light just how much "the cost of paranoia" is probably much further off base than a lot of "critical analysis" has placed it. So, if you own an ice cream shop that hosts a static public page on the cloud, it probably doesn't mean much (at least, you're no worse off than otherwise). But just about anything private? That's where the discussion of "security" is most often brought up and where "paranoia" tends to exist.

Re:This isn't a big deal, it's fucking huge.

[Sarten-X]

I think you've missed the point.

Without defining the boundaries of what is "secure", you can't say something is "insecure". You have to determine what level of risk is acceptable to be "secure" before you start deciding that certain implementation options are "insecure".

To hijack your particular example, I could argue (with a suitable amount of paranoia) that Google, Microsoft, and DropBox could all inject malware into their client software to harvest encryption keys from your computer. You could put the keys on another server, but that would only add a layer of protection that a well-compensated mole could bypass.

Of course, that's rather ridiculous. We generally assume that Google, Microsoft, and DropBox are extremely unlikely to embed key-harvesting malware in their software, so we accept that remote risk and say their services are secure. By extension, then, any service that isn't compatible with client-side encryption is "insecure" in comparison.

Reining in the paranoia further, we must consider the sensitivity of the data being protected. For example, what is the actual risk that Google, Microsoft, or DropBox will be compromised (internally or externally) to access our data? Perhaps we're storing prototype designs. If stolen, there would be a business impact, but no regulatory or legal impact, and customers wouldn't be affected. In that case, it may not be worth the expense and hassle to require end-to-end encryption. While the risk is indeed higher than the fully-encrypted scenario, the risk is low enough that we can still consider the implementation to be "secure" against reasonable threats.

Leaving paranoia behind entirely, I'll reuse the example from my earlier post: a company's archive of already-released press releases. In this application, having information available to the public is a good thing, as surely you would want your company's legacy to be available for any positive public relations. Obviously, if the data is released (again), there is no negative impact to investors, customers, or your business. A cheap hosting provider may be the best option, even if their security only goes so far as a contract promising that if your repository is hacked, they'll pay for damages.

The problems with outsourcing come from a failure in properly assessing risk, or applying an existing implementation to something with different impact. For example, dropping medical records on a preexisting public-facing FTP site would be grossly insecure, but it's secure enough to use that public FTP site to host blank forms for patients and other agencies to download (and return via secure channels).

Re: This isn't a big deal, it's fucking huge.

[Anonymous Coward]

US and UK isn't my government. Talking down the value of a business's trade and commercial secrets does not lessen the true value of those secrets.

Considering cloud 'risk' as acceptable when there is an option without those risks is foolish. You could not comply with EU privacy laws if your put your customers data in a US cloud. It not longer becomes about risk, but liability.

Re: This isn't a big deal, it's fucking huge.

[Sarten-X]

Well, yes. Those regulations are important, and regulatory compliance is part of what must be considered when finding an appropriate implementation.

As with all regulations, get a lawyer to determine exactly what is or is not necessary. I'm not an expert on the EU laws, but I wouldn't be surprised to find that they specifically exempt lawful searches by law enforcement personnel having jurisdiction, which would permit the US government to see your US-hosted data.

Those regulations may also be a reason to segregate your data. If it's cheaper to use a US-based cloud provider, you may be able to host only your private data in the EU in compliance with privacy laws, while hosting other assets with the cheaper American provider, reducing overall expenses.

Then again, maybe the simplicity of having everything in one place is the cost-effective option, with the labor savings outweighing the expense of having unnecessary protection.

I never said the analysis would be easy. I said it must be done. Nobody else can make your decisions for you and your data.

Re:This isn't a big deal, it's fucking huge.

[St.Creed]

Exactly this. If you don't control the bare metal, then the VM isn't fully trustworthy. Even before the details of the attack were worked out, this should have been an obvious conclusion.

That doesn't have to be the case. I know that at the very least two very large companies are working on fully encrypted computing, where nothing is ever decrypted on the server and all operations remain encrypted. *ALL* operations. One solution is apparently still slow as molasses (1 second for a multiplication or something in that order), but the one from ah... the other company, is a great deal faster. And it enables you to run fully secure in situations where you *know* the VM is untrusted.

Re:This isn't a big deal, it's fucking huge.

[Interfacer]

Somehow, at some point, the hardware owned by the hosting provider has to physically do
a * b
In order to calculate the result.
No matter the encryption used, at that point the data is unencrypted.

Re: This isn't a big deal, it's fucking huge.

[Anonymous Coward]

Get in the shower freak, the chair you're sitting in smells like your own ass.

Yes it's that obvious.

Re:This isn't a big deal, it's fucking huge.

[St.Creed]

Nope. The method works by doing this operation encrypted. So if A is a-encrypted and B is b-encrypted, it can do A*B and give you an encrypted result C that, when decrypted, gives you the result of a *b.

Mathematically, it's feasible but very hard.

Re: This isn't a big deal, it's fucking huge.

[tepples]

US and UK isn't my government.

Please tell me this wasn't meant as "I got mine". Otherwise, how many refugees from the surveillance regime in US and UK is your government willing to absorb?

You could not comply with EU privacy laws if your put your customers data in a US cloud.

If two jurisdictions each have privacy laws with strong incentives for local storage, where should data about a transaction between a user in one such jurisdiction and a user in the other be stored?

Re:This isn't a big deal, it's fucking huge.

[cryptizard]

The filesystem could be encrypted though, unlocked with a password/key that is stored in memory. So yes, it is quite possible that memory extraction is necessary. And I would argue that the contribution of this paper is making the necessary memory introspection sufficiently quick and painless so that the VM cannot find out that something fishy is going on.

Re:This isn't a big deal, it's fucking huge.

[cryptizard]

Other posters have mentioned homomorphic encryption but it could also be done inside a trusted enclave which is not able to be inspected by anything other than the executing process (even the operating system or hypervisor), see Intel Software Guard Extensions.

Re: This isn't a big deal, it's fucking huge.

[Anonymous Coward]

Just a tip: the Russians, Chinese and Iranians are all trying to hack away all day. The stuff they sell, if it's technically advanced enough will all come with the same malware freebies so they can spy on you. At least our governments are somewhat honest about it, rather than stonewall silence or denial.

Re:This isn't a big deal, it's fucking huge.

[whoever57]

Anyone running a business in a rented office should assume that the building owner sees everything that is happening in the office

And people decry slippery slope arguments.

Re: This isn't a big deal, it's fucking huge.

[Matt.Battey]

That's an important point, and allows for the server to be spoofed. But I think that the intent here is that active communications between server and client can be eaves dropped on. During the handshake, a symmetric cipher is selected and a key exchanged. It's this second key that normally cannot be accessed. Once a third party has access to this, they can see everything.

Re:This isn't a big deal, it's fucking huge.

[AcidPenguin9873]

Have you seen what AMD is putting into its next server processors? http://amd-dev.wpengine.netdna... Tldr: It encrypts a guest's memory with a key that the hypervisor does not have. In theory, it should make a guest VM inaccessible to the hypervisor.

Re: This isn't a big deal, it's fucking huge.

[Anonymous Coward]

The real problem is that the chips are likely backdoored as well, it would just be too easy to add microcode (or even silicon) to commonly used components and no one would be the wiser. I wouldn't trust anything manufactured or designed in a five eyes country or one of their close allies (Japan, Korea, Germany, etc). Why do you think the Russians and Chinese are manufacturing their own chips now? I wouldn't even trust an FPGA now.

The sooner we get open source hardware that includes verification capabilities the better.

Re: This isn't a big deal, it's fucking huge.

[Anonymous Coward]

UK just passed snoopers charter, that requires decryption. That decryption does not respect privacy treaties and UK has been caught spying on its neighbours, e.g. belgacom. Thus it means we cannot use UK kit. *UK* companies too, cannot use UK kit. Because while they may be aware of their own company being served with a backdoor demand, they cannot be aware of their suppliers being served with a backdoor demand. Their product may be backdoored and they wouldn't know it.
They cannot sell their product to large parts of the world because they cannot comply with the privacy right. It's a taint on UK manufacturing. UK Cloud services, telecoms, etc. Even UK owned businesses abroad are tainted by that law.

For UK, that means some high end telecoms, comms satellites, cloud services, biometrics etc.

It's not my problem that your cloud services have yet another vulnerability. Your problems and your governments are your responsibility. We are not a refugee camp for people fleeing their military industrial complex. However companies are free to setup here, and shift their manufacturing to a country where their products don't suffer the Theresa May taint.

Re: This isn't a big deal, it's fucking huge.

[Anonymous Coward]

Leaving paranoia behind? It's proof of an automated key harvesting algorithm for cloud services. Ignoring it doesn't make it go away.

Trying to factor such a major security hole into a business as 'acceptable', well good luck with that.

Re: This isn't a big deal, it's fucking huge.

[Anonymous Coward]

The same sort of people who insist on in strict building security, won't let you use your phone at work, etc. just totally ignore things like this for some reason.

I know if my company had secret research, especially for products that compete with big corporate interests that putting that on a cloud server is the same as emailing it to my competition. Governments do corporate espionage too you know. Why else would three big corporations that dictate everything else to the government be so silent with this stuff?

Re:This isn't a big deal, it's fucking huge.

[Attila Dimedici]

Cloud providers, for instance, will usually be quite happy to enter contracts promising that they'll protect your data from illegal release,

The key word here being "illegal release" and what the definition of "illegal" is. "Oh, that wasn't an illegal release, a government agency provided us with a official letter telling us to release that information to them. How were we supposed to know that wasn't legal?"

This study shows what should have been obvious to everyone: if you put your data on someone else's server (the cloud), you are putting your data in their control. It is then your data only so long as it is in their best interests for you to have it.

I am confident that if someone else controls the hypervisor there will be a way for that someone else to access the data stored on any virtual machines running on that hypervisor. You say that the cloud is not any more inherently insecure than hosting your own servers. However, that is clearly not true, because if I host my own servers, I can determine exactly who has access to them (the fact that many IT departments do not keep their servers any more secure than if they were on the "cloud" does not mean that it is not possible). Further, you argue against something I never said. I never said that there was not a valid use for the "cloud", all I said was that it is inherently insecure. If you need a place to store data that does not need security, the "cloud" is perfectly acceptable.

Re: This isn't a big deal, it's fucking huge.

[tepples]

However companies are free to setup here

Not if said companies' owners can't legally immigrate, or if engineers experienced with said companies' technology can't legally immigrate.

Re:This isn't a big deal, it's fucking huge.

[epine]

Anyone running a business in a rented office should assume that the building owner sees everything that is happening in the office.

And people decry slippery slope arguments.

Human paranoia: massless pulley pomade and frictionless rope tallow repackaged in a rusty 1970s aerosol spray can as Universal Slope Lube (earth-destroying propellant undisclosed).

Step 1: assume adversaries reside in frictionless hyperspace

Step 2: notice what they can do

Step 3: apply Murphy's law

Step 4: adorn self with tin foil

Step 5: worry about whisker growth causing pin holes

Re: This isn't a big deal, it's fucking huge.

[Anonymous Coward]

You guys are too funny. I have customers that think putting the data on a server in the Cayman is safer then putting the data in a server in the UK or USA. If the three letter agencies want your data, they already have it. No matter where it is or whether you run on bare metal or in a hypervisor. Stop whining and worry about your credit card company. They know what toilet paper you will purchase next week.

Engineering Paper

[bill_mcgonigle]

Skimmed the paper. It looks like a fair description of an engineering approach to exploit what we all already knew about hypervisors' access to their guests' memory and networking components. I don't see any revelations, just confirmation that you're not safe against a hostile hypervisor, with a somewhat practical attack method.

Re:Engineering Paper

[Anonymous Coward]

The next reveleation is that with physical access to the host servers, employees at datacenters could access any of the hard drives in a cloud environment, or even crash our machines indefinitely resulting in data loss!

Re: Engineering Paper

[Anonymous Coward]

It's the next step in this. Previously a hostile hypervisor would have to have a specific modification to pull the keys per target, now its been show to be trivial to have a generic modification to pull TLS session keys.

Automated backdoors, and generating and obfuscating the keys no longer works to make it more difficult to grab them, they key is grabbed at creation.

Re:Engineering Paper

[Gr8Apes]

The revelation is that it is trivial to accomplish this.

Intel SGX

[WorBlux]

A possible mitigation?

Re:Intel SGX

[cryptizard]

If you trust Intel, then yes. It is designed expressly to address situations like this.

A sidenote

[Artem S. Tashkinov]

While I commend the guys at BitDefender for finding this vulnerability its severity as a tad overstated.

Most if not all virtual machines are not encrypted, so your hosting provider has full access to your encryption keys which means there are easier ways to decrypt/intercept traffic.

Presumably you can solve this problem by using full disk encryption but then you need to find a way to pass your encryption password to your virtual host and you will surely do that through the means provided by your hosting provider, which means your password will be intercepted en route and again your hosting provider will have full access to the disk image.

In short you cannot trust anything you're not running from your own physically secured environment.

And even in your own fully secured physical environment you're still f*cked.

Re:A sidenote

[Artem S. Tashkinov]

The researchers actually admit (actual PDF) what I'm saying: "Actually, if you're not in control of the bare metal all bets are off"

Re:A sidenote

[sciport]

Most if not all virtual machines are not encrypted, so your hosting provider has full access to your encryption keys which means there are easier ways to decrypt/intercept traffic.

Are you refering to the SSL/TLS RSA keys stored on the filesystem for web servers? Because if yes, then you are not entirely correct. There are cipher suites (preferred by browsers) that have Perfect Forward Secrecy such that even if you later obtain those keys you can't decrypt past traffic.

Re:A sidenote

[guruevi]

The hypervisor also has access to your memory and until calculations on encrypted data becomes feasible, whoever owns the physical memory can read it out. Hell, most hypervisors can attach a console to the machine or even clone a running machine onto another machine without the VM being any the wiser. Disk encryption is only useful for data at rest and on the move, once you have unlocked the data at boot time, whoever owns the machine can read it.

Re:A sidenote

[Anonymous Coward]

You're posting a pdf on a story about security breaches? Cheeky!

Re:A sidenote

[RatherBeAnonymous]

"Presumably you can solve this problem by using full disk encryption..."

No, you can't. If I am reading this correctly, this vulnerability is about the TLS session keys. RSA uses asymmetrical encryption, via the public/private key pair, to negotiate a symmetrical encryption key that is used for the data transfer session. That session key will be exposed in memory. DHE and ECDHE keys have capability called "perfect forward secrecy". If a man-in-the-middle attacker records all traffic between server and client and later obtains or cracks the private RSA key, he can use that to decipher the session keys and decrypt all data. DHE and ECDHE protect against that attack vector. But I don't see how they could protect against an attacker with full control of the virtual host who can manage to read the TLS session keys right out of memory.

Re: A sidenote

[Anonymous Coward]

Until that is cracked

Re:A sidenote

[cryptizard]

Intel Software Guard Extensions are designed to address exactly this situation. A process can run code in a trusted enclave such that no other process (even the operating system or hypervisor) can inspect the contents of that process. If you trust that Intel has implemented it correctly, then you actually can securely deploy things on untrusted servers.

Re:A sidenote

[guruevi]

IF you trust Intel AND trust the hypervisors to be honest about the capabilities of the processor at all times AND use the features. If you trust the hypervisors then you never have any problems, this is about untrusted hypervisors, emulating a processor feature is trivial.

Re:A sidenote

[cryptizard]

No you don't have to trust the hypervisor, there is a method for the processor to cryptographically attest that it supports SGX in a way that the hypervisor cannot "fake" an SGX container. You are completely right that you have to trust Intel though.

Re:A sidenote

[guruevi]

QEMU can emulate SGX. There is a paper somewhere that shoots holes in all the 'promises', it's basically TPM but for VM's, you have to code specifically for it and license it from Intel and only Intel can 'verify' (which as we know, no American company can be trusted when it comes to turning over their private keys to the state).

Re:A sidenote

[cryptizard]

QEMU can emulate using OpenSGX, where you generate the certificates yourself. This allows people to test out SGX code but it is NOT able to transparently impersonate an SGX processor, which would attest with a certificate signed by Intel. And I'm not sure what you mean by licensing SGX, it is free and the SDK is GPL.

Re: A sidenote

[Anonymous Coward]

My hosting provider is too stupid and incompetent to extract keys. However, with a plug-in that does it for them, their most basic lacky could be getting them. Script kiddies dream.

There is no cloud, just other people's computers.

[ffkom]

And those who own/operate those computers can, of course, eavesdrop whatever their "virtual" guests are doing. Seriously, how could anyone ever think otherwise?

Cloud Providers and the Feds.

[bmo]

Today there is a more recent story about the DEA spying on your medication list:

Unlike in cases of commercially-held data, where the Third Party doctrine allows police warrantless access, prescription drug monitoring databases are maintained by state-governments. The difference is lost to the Obama Administration, which argues that "since the records have already been submitted to a third party (a state's Prescription Drug Monitoring Program) that patients no longer enjoy an expectation of privacy."

You don't think they would apply the third-party doctrine to your data in the cloud, would they? Naw...

They don't need to break TLS. They just have to ask your provider "nicely" in a "youse got a nice restaurant here, it'd be too bad if it burned down" kinda way. Because you no longer own your data, they do.

Welcome to the police state. Thanks a lot, Tricky Dick, Ronnie Raygun, GHWB, Bill Clinton, Bob Graham (not a president, but he wrote most of the Patriot Act), GWB, Obama. (not sure about Carter expanding the drug war that Nixon started. Wouldn't surprise me if he did).

And it's guaranteed that Hills will continue the fine tradition.

In the unlikely event that Der TrumpenFuehrer gets elected, he's dumb and cowardly enough to be talked into also continuing the fine tradition. He'll be a patsy like GWB was.

Hills will be more direct.

We're fucked.

--
BMO

Your privacy

[JustAnotherOldGuy]

It's gone.

For a determined party (FBI, CIA, NSA, etc etc) your privacy is merely an inconvenience, and not a terribly burdensome one at that.

Re:Your privacy

[Anonymous Coward]

Hate to tell you, but there is no privacy in "public"

That includes the internet.

If you assume otherwise, you're the idiot here.

Re:Your privacy

[Anonymous Coward]

Hate to tell you, but there is no privacy in "public"

That includes the internet.

If you assume otherwise, you're the idiot here.

The Internet (from your home), (from a park lawn), (from your bathroom), (from your office cubicle), (from your White House desk) is only public if you intend it to be.

This is the reason when you look up SSL and HTTPS and CA Certs and sha256 etc etc they are ENCRYPTED.

If something is encrypted, it is not public. The Internet is encrypted. You are a douche. Carry on washing your vagina.

Does Microsoft's Guarded Fabric help?

[mlts]

Makes me wonder if the Guarded Fabric/Shielded VMs in Hyper-V, coming in Windows Server 2016 is a definite answer to this type of attack, especially if it takes advantage of hardware RAM encryption in the latest AMD and Intel chipsets.

Not to praise MS, but it is interesting that they have a hardware based stack that might defend against this.

uefi inf0rmation censorship spyware super highway

[Anonymous Coward]

WHERE ARE THE DETAILS?

you'll uefu bnever find it on the intornet. . (the dumbest of) dumb ass conspiracies, spywarZ, engineered search manipulation ( Systematic coverup, copies of copies of copies of the same disinformation,

this is homicidal fucking insanity

All your base are belong to us.

[Anonymous Coward]

Sincerely 3 letter agency's.

Craig Gentry's homomorphic encryption

[tepples]

Not if it computes some f(a, b) that doesn't have a * b as a step but still has a distributive property such that decrypt(f(a, b)) == decrypt(a) * decrypt(b). See the explanation of Craig Gentry's Ph.D. thesis on "Homomorphic encryption" on Wikipedia.

Re:Craig Gentry's homomorphic encryption

[Anonymous Coward]

Yeah, right. Not going to fall for Goat.se again.

You still need to sign your press releases

[tepples]

Leaving paranoia behind entirely, I'll reuse the example from my earlier post: a company's archive of already-released press releases. In this application, having information available to the public is a good thing, as surely you would want your company's legacy to be available for any positive public relations. Obviously, if the data is released (again), there is no negative impact to investors, customers, or your business.

If the data is falsified and then released, it can still harm your business. For this you need signatures for authentication and integrity even if not encryption for confidentiality.

We need another President Johnson

[tepples]

In the unlikely event that Der TrumpenFuehrer gets elected, he's dumb and cowardly enough to be talked into also continuing the fine tradition. He'll be a patsy like GWB was.

Hills will be more direct.

What we need is another President Johnson. Independents agree.

Re:We need another President Johnson

[dbIII]

The guy who lied to start a war? Oh that's happened since from the other side of politics, fair enough.

"System memory readable by system administrator"

[Anonymous Coward]

The headline isn't very catchy but that's really all this boils down to. Whatever the flavor, a VM is ultimately just a program being run by an OS (the host OS or hypervisor). "Oh, but hardware virtualization!" Regular programs get hardware virtualization too -- virtual address space being the classic example.

Huh. Never thought much about it...but AWS...

[WoTG]

Anyone who has used 3rd party "web hosting"... should know this. At least my current web host has the decency to pretend they can't see my files without my password when I ask for support. :)

I hadn't thought about it much, but Amazon, through the sheer scale of AWS is trusted with a whole lot of data. What does their ToS say they can do with it?

ROFL

[Anonymous Coward]

"CIOs who are outsourcing their virtualized infrastructure to a third-party vendor should assume that all of the information flowing between the business and its customers has been decrypted and read for an undetermined amount of time."

But the article writer uses a cell phone.

Idiots

[Anonymous Coward]

Why would you assume all your data has been read. That's such a load of BS fear based marketing.

Chances are in every possible way that your network has not been affected by this exploit, plain and simple. There is no mass spying conspiracy to use every known exploit to mass spy on every packet of data. That's just for profit fear.

Buy real and fake Passport ,Visa,Driving License,I

[pauldocument]

Buy real and fake Passport ,Visa,Driving License,ID CARDS,marriage certificates,diplomas etc for sell Guaranteed 24 hour passport,citizenship,Id cards,drivers license,diplomas,degrees,certificates service available. Tourist and business visa services available to residents of all 50 states and all nationalities Worldwide. are unique producers of Authentic High Quality passports, Real Genuine Data Base Registered and unregistered Passports and other Citizenship documents.I can guarantee you a new Identity starting from a clean new genuine Birth Certificate, ID card, Drivers License,Passports, Social security card with SSN, credit files, and credit cards, school diplomas, school degrees all in an entirely new name issued and registered in the government database system.. We use high quality equipment and materials to produce authentic and counterfeit documents.All secret features of real passports are carefully duplicated for our Registered and unregistered documents.we are unique producer of quality false and Real documents.We offer only original high-quality Registered and unregistered passports, drivers licenses, ID cards, stamps, Visa, school Diplomas and other products for a number of countries like:USA, Australia, Belgium,Brazil, Canada, Italian,Finland, France, Germany, Israel, Mexico, Netherlands, South Africa,Spain, United Kingdom. UNIVERSAL PAPERS Contact us on................pauldocument508@gmail.com General Support:-------- pauldocument508@gmail.com we are able to produce the following items; REAL BRITISH PASSPORT. REAL CANADIAN PASSPORT. REAL FRENCH PASSPORT. REAL AMERICAN PASSPORT. REAL RUSSIAN PASSPORT. REAL JAPANESSE PASSPORT. REAL CHINESSE PASSPORT. AND REAL PASSPORT FOR COUNTRIES IN THE EUROPEAN UNION. REAL DRIVERS LICENSE,I.D CARDS,BIRTH CERTIFATES,DIPLOMATS,MARRIGE CERTIFICATES,AND VISAS. REGISTERED AND UNREGISTERED BRITISH PASSPORT. REGISTERED AND UNREGISTERED CANANIAN PASSPORT. REGISTERED AND UNREGISTERED FRENCH PASSPORT. REGISTERED AND UNREGISTERED AMERICAN PASSPORT. REGISTERED AND UNREGISTERED RUSSSIAN PASSPORT. REGISTERED AND UNREGISTERED JAPANESSE PASSPORT. REGISTERED AND UNREGISTERED CHINESSE PASSPORT. REGISTERED AND UNREGISTERED PASSPORTPASSPORT FOR COUNTRIES IN THE EUROPEAN UNION. Buy Registered and unregistered USA(United States) passports, Buy Registered and unregistered Australian passports, Buy Registered and unregistered Belgium passports, Buy Registered and unregistered Brazilian(Brazil) passports, Buy Registered and unregistered Canadian(Canada) passports, Buy Registered and unregistered Finnish(Finland) passports, Buy Registered and unregistered French(France) passports, Buy Registered and unregistered German(Germany) passports, Buy Registered and unregistered Dutch(Netherland/Holland) passports, Buy Registered and unregistered Israel passports, Buy Registered and unregistered UK(United Kingdom) passports, Buy Registered and unregistered Spanish(Spain) passports, Buy Registered and unregistered Mexican(Mexico) passports, Buy Registered and unregistered South African passports. Buy Registered and unregistered Australian driver licenses, Buy Registered and unregistered Canadian driver licenses, Buy Registered and unregistered French(France) driver licenses, Buy Registered and unregistered Dutch(Netherland/Holland) driving licenses, Buy Registered and unregistered German(Germany) driving licenses, Buy Registered and unregistered UK(United Kingdom) driving licenses, Buy Registered and unregistered Diplomatic passports, Buy Registered and unregistered USA(United States) passports, Buy Registered and unregistered Australian passports, Buy Registered and unregistered Belgium passports, Buy Registered and unregistered Brazilian(Brazil) passports, Buy Registered and unregistered Canadian(Canada) passports, Buy Registered and unregistered Finnish(Finland) passports, Buy Registered and unregistered French(France) passports, Buy Registered and unregistered German(Germany) passports, Buy Registered and unregistered Dutch(Netherland/Holland) passports, Buy Registered and unregister

Re:There is no cloud, just other people's computer

[Anonymous Coward]

The same people who think there is a cloud. Blame marketing and those without knowledge of how things actually work.