17.1 C
London
Saturday, September 23, 2017
Home Tags Smartcard

Tag: Smartcard

Senate employees just use passwords, and their badges sport a picture of an alternative.
Aurich Lawson / Thinkstockreader comments 25 Share this story Neal H. Walfield is a hacker at g10code working on GnuPG.

This op-ed was written for Ars Technica by Walfield, in response to Filippo Valsorda's "I'm giving up on PGP" story that was published on Ars last week. Every once in a while, a prominent member of the security community publishes an article about how horrible OpenPGP is. Matthew Green wrote one in 2014 and Moxie Marlinspike wrote one in 2015.

The most recent was written by Filippo Valsorda, here on the pages of Ars Technica, which Matthew Green says "sums up the main reason I think PGP is so bad and dangerous." In this article I want to respond to the points that Filippo raises.
In short, Filippo is right about some of the details, but wrong about the big picture.

For the record, I work on GnuPG, the most popular OpenPGP implementation. Forward secrecy isn't always desirable Filippo's main complaint has to do with OpenPGP's use of long-term keys.
Specifically, he notes that due to the lack of forward secrecy, the older a key is, the more communication will be exposed by its compromise.

Further, he observes that OpenPGP's trust model includes incentives to not replace long-term keys. First, it's true that OpenPGP doesn't implement forward secrecy (or future secrecy).

But, OpenPGP could be changed to support this. Matthew Green and Ian Miers recently proposed puncturable forward secure encryption, which is a technique to add forward secrecy to OpenPGP-like systems.

But, in reality, approximating forward secrecy has been possible since OpenPGP adopted subkeys decades ago. (An OpenPGP key is actually a collection of keys: a primary key that acts as a long-term, stable identifier, and subkeys that are cryptographically bound to the primary key and are used for encryption, signing, and authentication.) Guidelines on how to approximate forward secrecy were published in 2001 by Ian Brown, Adam Back, and Ben Laurie.

Although their proposal is only for an approximation of forward secrecy, it is significantly simpler than Green and Miers' approach, and it works in practice. As far as I know, Brown et al.'s proposal is not often used. One reason for this is that forward secrecy is not always desired.

For instance, if you encrypt a backup using GnuPG, then your intent is to be able to decrypt it in the future.
If you use forward secrecy, then, by definition, that is not possible; you've thrown away the old decryption key.
In the recent past, I've spoken with a number of GnuPG users including 2U and 1010data.

These two companies told me that they use GnuPG to protect client data.

Again, to access the data in the future, the encryption keys need to be retained, which precludes forward secrecy. This doesn't excuse the lack of forward secrecy when using GnuPG to protect e-mail, which is the use case that Filippo concentrates on.

The reason that forward secrecy hasn't been widely deployed here is that e-mail is usually left on the mail server in order to support multi-device access.
Since mail servers are not usually trusted, the mail needs to be kept encrypted.

The easiest way to accomplish this is to just not strip the encryption layer.
So, again, forward secrecy would render old messages inaccessible, which is often not desired. But, let's assume that you really want something like forward secrecy.

Then following Brown et al.'s approach, you just need to periodically rotate your encryption subkey.
Since your key is identified by the primary key and not the subkey, creating a new subkey does not change your fingerprint or invalidate any signatures, as Filippo states.

And, as long as your communication partners periodically refresh your key, rotating subkeys is completely transparent. Ideally, you'll want to store your primary key on a separate computer or smartcard so that if your computer is compromised, then only the subkeys are compromised.

But, even if you don't use an offline computer, and an attacker also compromises your primary key, this approach provides a degree of future secrecy: your attacker will be able to create new subkeys (since she has your primary key), and sign other keys, but she'll probably have to publish them to use them, which you'll eventually notice, and she won't be able to guess any new subkeys using the existing keys. Enlarge / Circuit Benders and more at the 2011 Doo Dah Parade. Sheyneinlalaland Physical attacks vs. cyber attacks So, given that forward secrecy is possible, why isn't it enabled by default? We know from Snowden that when properly implemented, "encryption … really is one of the few things that we can rely on." In other words, when nation states crack encryption, they aren't breaking the actual encryption, they are circumventing it.

That is, they are exploiting vulnerabilities or using national security letters (NSLs) to break into your accounts and devices.

As such, if you really care about protecting your communication, you are much better off storing your encryption keys on a smartcard then storing them on your computer. Given this, it's not clear that forward secrecy is that big of a gain, since smartcards won't export private keys.
So, when Filippo says that he is scared of an evil maid attack and is worried that someone opened his safe with his offline keys while he was away, he's implicitly stating that his threat model includes a physical, targeted attack.

But, while moving to the encrypted messaging app Signal gets him forward secrecy, it means he can't use a smartcard to protect his keys and makes him more vulnerable to a cyber attack, which is significantly easier to conduct than a physical attack. Another problem that Filippo mentions is that key discovery is hard.
Specifically, he says that key server listings are hard to use.

This is true.

But, key servers are in no way authenticated and should not be treated as authoritative.
Instead, if you need to find someone's key, you should ask that person for their key's fingerprint. Unfortunately, our research suggests that for many GnuPG users, picking up the phone is too difficult. So, after our successful donation campaign two years ago, we used some of the money to develop a new key discovery technique called the Web Key Directory (WKD).

Basically, the WKD provides a canonical way to find a key given an e-mail address via HTTPS.

This is not as good as checking the fingerprint, but since only the mail provider and the user can change the key, it is a significant improvement over the de facto status quo. WKD has already been deployed by Posteo, and other mail providers are in the process of integrating it (consider asking your mail provider to support it). Other people have identified the key discovery issue, too. Micah Lee, for instance, recently published GPG Sync, and the INBOME group and the pretty Easy privacy (p≡p) project are working on opportunistically transferring keys via e-mail. Signal isn't our saviour Filippo also mentions the multi-device problem.
It's true that using keys on multiple devices is not easy. Part of the problem is that OpenPGP is not a closed ecosystem like Signal, which makes standardising a secret key exchange protocol much more difficult. Nevertheless, Tankred Hase did some work on private key synchronisation while at whiteout.io.

But, if you are worried about targeted attacks as Filippo is, then keeping your keys on a computer, never mind multiple computers, is not for you.
Instead, you want to keep your keys on a smartcard.
In this case, using your keys from multiple computers is easy: just plug the token in (or use NFC)! This assumes that there is an OpenPGP-capable mail client on your platform of choice.

This is the case for all of the major desktop environments, and there is also an excellent plug-in for K9 on Android called OpenKeychain. (There are also some solutions available for iOS, but I haven't evaluated them.) Even if you are using Signal, the multi-device problem is not completely solved.

Currently, it is possible to use Signal from a desktop and a smartphone or a tablet, but it is not possible to use multiple smartphones or tablets. One essential consideration that Filippo doesn't adequately address is that contacting someone on Signal requires knowing their mobile phone number. Many people don't want to make this information public.
I was recently chatting with Jason Reich, who is the head of OPSEC at BuzzFeed, and he told me that he spends a lot of time teaching reporters how to deal with the death and rape threats that they regularly receive via e-mail.

Based on this, I suspect that many reporters would opt to not publish their phone number even though it would mean missing some stories.
Similarly, while talking to Alex Abdo, a lawyer from the ACLU, I learned that he receives dozens of encrypted e-mails every day, and he is certain that some of those people would not have contacted him or the ACLU if they couldn't remain completely anonymous. Another point that Filippo doesn't cover is the importance of integrity; he focused primarily on confidentiality (i.e., encryption).
I love the fact that messages that I receive from DHL are signed (albeit using S/MIME and not OpenPGP).

This makes detecting phishing attempts trivial.
I wish more businesses would do this. Of course, Signal also provides integrity protection, but I definitely don't want to give all businesses my phone number given their record of protecting my e-mail address. Moreover, most of this type of communication is done using e-mail, not Signal. I want to be absolutely clear that I like Signal. When people ask me how they can secure their communication, I often recommend it.

But, I view Signal as complementary to OpenPGP.

First, e-mail is unlikely to go away any time soon.
Second, Signal doesn't allow transferring arbitrary data including documents.

And, importantly, Signal has its own problems.
In particular, the main Signal network is centralised, not federated like e-mail, the developers actively discourage third-party clients, and you can't choose your own identity.

These decisions are a rejection of a free and open Internet, and pseudononymous communication. In conclusion, Filippo has raised a number of important points.

But, with respect to long-term OpenPGP keys being fatally flawed and forward secrecy being essential, I think he is wrong and disagree with his compromises in light of his stated threat model.
I agree with him that key discovery is a serious issue.

But, this is something that we've been working to address. Most importantly, Signal cannot replace OpenPGP for many people who use it on a daily basis, and the developers' decision to make Signal a walled garden is problematic.
Signal does complement OpenPGP, though, and I'm glad that it's there. Neal H. Walfield is a hacker at g10code working on GnuPG. His current project is implementing TOFU for GnuPG.

To avoid conflict of interests, GnuPG maintenance and development is funded primary by donations. You can find him on Twitter @nwalfield.
E-mail: neal@gnupg.org OpenPGP: 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9 This post originated on Ars Technica UK
Google is making it possible for enterprises to cryptographically validate Chrome OS devices before letting them connect to secure networks with its new Verified Access for Chrome OS. With Verified Access, network services -- VPN gateways, sensitive servers, an enterprise certificate authority, enterprise Wi-Fi access points -- can get a hardware-backed cryptographic guarantee from the client machine that it has not been compromised and the user is who he or she claims to be. Verified Access uses the Trusted Platform Module chip present on all Chrome OS devices to confirm the device is unmodified and complies with existing security policies.

The network service uses that information to determine what level of access the device gets to sensitive corporate systems and applications. The combination of a cryptographic attestment of the device's untampered state, anchored to a chip on the device, has long been used in Apple's iOS devices, BlackBerrys, and Samsung's higher-end Android devices.

The Trusted Platform Module chip used in Chrome OS devices has been available on higher-end Windows PCs for several years as well, though its use there is typically tied to validating the encryption key in a tamperproof manner. "For years, Google has been using Verified Access to enhance security by ensuring the veracity and policy compliance of Chrome devices before allowing access to resources, and now we are making it available externally," Saswat Panigrahi, senior product manager for Chrome for Work, wrote on the Google for Work blog. The Chrome OS Verified Access API is now publicly available and configurable in the Google Apps Admin Panel.

Administrators get started by enabling Verified Access and granting access to use the enterprise.platformKeys API.

A Chrome extension also needs to be installed on the devices to interact with the enterprise.platformKeys API. ID, please Enterprises typically have policies in place to restrict network and data access only to corporate-issued and verified devices, but they rely on client-side methods to verify the devices.

A malicious actor who has compromised the operating system can conceivably fake the signals and bypass the client-side checks. Verified Access obtains the cryptographic guarantee from the Trusted Platform Module chip present on the device and uses the Google server-side API to confirm the identity and status of the device.
It confirms the device is a real Chrome OS device and not some other hardware with the Chrome OS image installed, and the request was recently initiated and not an older, cached request.
Verified Access is managed by the corporate domain, so it can check the device against security settings and policies, as well as its compliance with internal policies.
It can also verify the user is a valid domain user. One potential scenario is to integrate Verified Access with an enterprise certificate authority.
In this case, hardware-protected device certificates can be distributed to only devices that IT manages and has verified.

A VPN gateway can be configured to authenticate the user with a certificate and issue that certificate if the user and device passes the Verified Access check, Panigrahi said.

This way, enterprises get a hardware-backed cryptographic guarantee of the identity of the device, the user, and its policy compliant state before granting them access to the protected resources behind the VPN. This setup would work many of  the popular commercial VPN gateways, including Pulse Secure VPN, Dell SonicWALL Mobile Connect, Cisco AnyConnect, F5 Access, GlobalProtect, OpenVPN, and L2TP over IPSec.
VPN vendors can build direct integrations with Verified Access, but it won't be necessary to get the benefits of the attestation protocol. As long as the VPN is set up to accept certificate-based authentication, a common arrangement among enterprises, certificate issuance can be conditioned on Verified Access without making additional changes on the gateway, Panigrahi said. The Chromebook security advantage Many organizations are giving Chromebooks to their employees because of their security advantages, such as the automatic operating system updates, sandboxing and isolation technologies, whitelists for trusted Chrome extensions, and built-in encryption.

Chrome OS also makes it easy to enforce policies, such as isolating the device to the Google Apps domain and using Verified Boot to complicate persistence across reboots.

For organizations relying heavily on cloud applications and email-based attachments, Chromebooks make a lot of sense. This is why cloud-based trusted access provider Duo Security has decided to issue Chromebooks to more than a quarter of its employees, across different job functions and departments. Over the past few months, Duo Security has been using Verified Access internally to assess Chromebooks before granting access to corporate resources, Michael Hanley, director of security at Duo Security, wrote in a blog post. In Duo's case, Verified Access passed the cryptographic guarantees to the company's trusted access service to make decisions about the level of access to grant to the device.

A login attempt passes a challenge from the Verified Access API to the Chrome extension (via the Chrome Message Passing API), which uses the enterprise.platformKeys API to get a response.

The challenge response is sent to Duo's service, which verifies it by sending it to the Verified Access API and receiving the response.

The service makes an access control decision based on that outcome.
If the device fails the protocol, then access is denied. "We use this to reliably assess the security posture of Chromebooks at Duo before they are allowed to access particularly sensitive resources," Hanley wrote. Duo Security and Ruckus Wireless has already integrated the Verified Access API with their offerings.

Duo plans to have general availability of Verified Access in Duo's Platform Edition later this year.

Administrators would be able to use Duo's service to make access control decisions based on information from Verified Access, much in the same way Duo currently uses the feature internally. "Part of the reason we like this feature is it's a very strong property based on how the protocol works and what it attests to and because it was very easy for us to deploy and manage," Hanley said.  Ruckus has integrated its Cloudpath ES security management platform with the API to securely differentiate between IT-owned and user-owned Chromebooks.

Cloudpath uses the API to ensure only IT-owned Chromebooks are allowed to join the wireless network or receive the certificate to access sensitive resources. Other identity, network, and security providers can follow Ruckus and Duo's example, but integrating their services with the Verified Access API.

Duo's Hanley said Verified Access required "very minimal adjustments" to deploy the API internally. "For customers that are heavy on Chromebooks and google Apps, the lift is surprisingly low considering what customers gain from this," Hanley said. Google has also been working on other ways to strengthen endpoint security on Chrome devices, such as adding Smartcard Authentication support.

The newly launched Citrix Receiver for Chrome 2.1 lets users authenticate to virtualized Citrix applications using smartcards.
If single sign-on is enabled, they can login to their Chromebook and automatically be authenticated across Citrix and virtualized Windows applications. At the moment, Verified Access is only available for Chrome devices, and there's no word on whether Google plans to expand the security feature for other TPM-enabled platforms.
Verified Access makes Chrome OS even more attractive in the enterprise endpoint security space.
An update for spice is now available for Red Hat Enterprise Linux 7.Red Hat Product Security has rated this update as having a security impact ofImportant.

A Common Vulnerability Scoring System (CVSS) base score, which givesa detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. The Simple Protocol for Independent Computing Environments (SPICE) is a remotedisplay system built for virtual environments which allows the user to view acomputing 'desktop' environment not only on the machine where it is running, butfrom anywhere on the Internet and from a wide variety of machine architectures.Security Fix(es):* A memory allocation flaw, leading to a heap-based buffer overflow, was foundin spice's smartcard interaction, which runs under the QEMU-KVM context on thehost.

A user connecting to a guest VM using spice could potentially use thisflaw to crash the QEMU-KVM process or execute arbitrary code with the privilegesof the host's QEMU-KVM process. (CVE-2016-0749)* A memory access flaw was found in the way spice handled certain guests usingcrafted primary surface parameters.

A user in a guest could use this flaw toread from and write to arbitrary memory locations on the host. (CVE-2016-2150)The CVE-2016-0749 issue was discovered by Jing Zhao (Red Hat) and theCVE-2016-2150 issue was discovered by Frediano Ziglio (Red Hat). For details on how to apply this update, which includes the changes described inthis advisory, refer to:https://access.redhat.com/articles/11258Applications acting as a SPICE server must be restarted for this update to takeeffect. Note that QEMU-KVM guests providing SPICE console access must berestarted for this update to take effect.Red Hat Enterprise Linux Desktop (v. 7) SRPMS: spice-0.12.4-15.el7_2.1.src.rpm     MD5: fa498221bcac8a0b6d7f5750b4d6106cSHA-256: 7f7d26048b3d202b50a0405b7de2cf51b4f0b25645723ff86b2484d381faf001   x86_64: spice-debuginfo-0.12.4-15.el7_2.1.x86_64.rpm     MD5: a846b173b0662df2d48f7ab38d9f1aa6SHA-256: cfdbf521f6edd70b9f0760eb8ff61c80b9eabcf875a99cb7ea203dd5546dc0f3 spice-server-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 86d5ac6bcf54a6e43b87e41ad875fce0SHA-256: 2456ef2cddf86fc496327c16f5d3784393d19d44c2d1614b97013ee241fd93df spice-server-devel-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 409a3c540f0f025c321ea6f1efff31ebSHA-256: afd2b0a278b7e62ef570c764e8d03cba6d925845e35bae78cd142fb7fffa1e8a   Red Hat Enterprise Linux HPC Node (v. 7) SRPMS: spice-0.12.4-15.el7_2.1.src.rpm     MD5: fa498221bcac8a0b6d7f5750b4d6106cSHA-256: 7f7d26048b3d202b50a0405b7de2cf51b4f0b25645723ff86b2484d381faf001   x86_64: spice-debuginfo-0.12.4-15.el7_2.1.x86_64.rpm     MD5: a846b173b0662df2d48f7ab38d9f1aa6SHA-256: cfdbf521f6edd70b9f0760eb8ff61c80b9eabcf875a99cb7ea203dd5546dc0f3 spice-server-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 86d5ac6bcf54a6e43b87e41ad875fce0SHA-256: 2456ef2cddf86fc496327c16f5d3784393d19d44c2d1614b97013ee241fd93df spice-server-devel-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 409a3c540f0f025c321ea6f1efff31ebSHA-256: afd2b0a278b7e62ef570c764e8d03cba6d925845e35bae78cd142fb7fffa1e8a   Red Hat Enterprise Linux HPC Node EUS (v. 7.2) SRPMS: spice-0.12.4-15.el7_2.1.src.rpm     MD5: fa498221bcac8a0b6d7f5750b4d6106cSHA-256: 7f7d26048b3d202b50a0405b7de2cf51b4f0b25645723ff86b2484d381faf001   x86_64: spice-debuginfo-0.12.4-15.el7_2.1.x86_64.rpm     MD5: a846b173b0662df2d48f7ab38d9f1aa6SHA-256: cfdbf521f6edd70b9f0760eb8ff61c80b9eabcf875a99cb7ea203dd5546dc0f3 spice-server-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 86d5ac6bcf54a6e43b87e41ad875fce0SHA-256: 2456ef2cddf86fc496327c16f5d3784393d19d44c2d1614b97013ee241fd93df spice-server-devel-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 409a3c540f0f025c321ea6f1efff31ebSHA-256: afd2b0a278b7e62ef570c764e8d03cba6d925845e35bae78cd142fb7fffa1e8a   Red Hat Enterprise Linux Server (v. 7) SRPMS: spice-0.12.4-15.el7_2.1.src.rpm     MD5: fa498221bcac8a0b6d7f5750b4d6106cSHA-256: 7f7d26048b3d202b50a0405b7de2cf51b4f0b25645723ff86b2484d381faf001   x86_64: spice-debuginfo-0.12.4-15.el7_2.1.x86_64.rpm     MD5: a846b173b0662df2d48f7ab38d9f1aa6SHA-256: cfdbf521f6edd70b9f0760eb8ff61c80b9eabcf875a99cb7ea203dd5546dc0f3 spice-server-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 86d5ac6bcf54a6e43b87e41ad875fce0SHA-256: 2456ef2cddf86fc496327c16f5d3784393d19d44c2d1614b97013ee241fd93df spice-server-devel-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 409a3c540f0f025c321ea6f1efff31ebSHA-256: afd2b0a278b7e62ef570c764e8d03cba6d925845e35bae78cd142fb7fffa1e8a   Red Hat Enterprise Linux Server AUS (v. 7.2) SRPMS: spice-0.12.4-15.el7_2.1.src.rpm     MD5: fa498221bcac8a0b6d7f5750b4d6106cSHA-256: 7f7d26048b3d202b50a0405b7de2cf51b4f0b25645723ff86b2484d381faf001   x86_64: spice-debuginfo-0.12.4-15.el7_2.1.x86_64.rpm     MD5: a846b173b0662df2d48f7ab38d9f1aa6SHA-256: cfdbf521f6edd70b9f0760eb8ff61c80b9eabcf875a99cb7ea203dd5546dc0f3 spice-server-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 86d5ac6bcf54a6e43b87e41ad875fce0SHA-256: 2456ef2cddf86fc496327c16f5d3784393d19d44c2d1614b97013ee241fd93df spice-server-devel-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 409a3c540f0f025c321ea6f1efff31ebSHA-256: afd2b0a278b7e62ef570c764e8d03cba6d925845e35bae78cd142fb7fffa1e8a   Red Hat Enterprise Linux Server EUS (v. 7.2) SRPMS: spice-0.12.4-15.el7_2.1.src.rpm     MD5: fa498221bcac8a0b6d7f5750b4d6106cSHA-256: 7f7d26048b3d202b50a0405b7de2cf51b4f0b25645723ff86b2484d381faf001   x86_64: spice-debuginfo-0.12.4-15.el7_2.1.x86_64.rpm     MD5: a846b173b0662df2d48f7ab38d9f1aa6SHA-256: cfdbf521f6edd70b9f0760eb8ff61c80b9eabcf875a99cb7ea203dd5546dc0f3 spice-server-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 86d5ac6bcf54a6e43b87e41ad875fce0SHA-256: 2456ef2cddf86fc496327c16f5d3784393d19d44c2d1614b97013ee241fd93df spice-server-devel-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 409a3c540f0f025c321ea6f1efff31ebSHA-256: afd2b0a278b7e62ef570c764e8d03cba6d925845e35bae78cd142fb7fffa1e8a   Red Hat Enterprise Linux Workstation (v. 7) SRPMS: spice-0.12.4-15.el7_2.1.src.rpm     MD5: fa498221bcac8a0b6d7f5750b4d6106cSHA-256: 7f7d26048b3d202b50a0405b7de2cf51b4f0b25645723ff86b2484d381faf001   x86_64: spice-debuginfo-0.12.4-15.el7_2.1.x86_64.rpm     MD5: a846b173b0662df2d48f7ab38d9f1aa6SHA-256: cfdbf521f6edd70b9f0760eb8ff61c80b9eabcf875a99cb7ea203dd5546dc0f3 spice-server-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 86d5ac6bcf54a6e43b87e41ad875fce0SHA-256: 2456ef2cddf86fc496327c16f5d3784393d19d44c2d1614b97013ee241fd93df spice-server-devel-0.12.4-15.el7_2.1.x86_64.rpm     MD5: 409a3c540f0f025c321ea6f1efff31ebSHA-256: afd2b0a278b7e62ef570c764e8d03cba6d925845e35bae78cd142fb7fffa1e8a   (The unlinked packages above are only available from the Red Hat Network) These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from:
An update for spice-server is now available for Red Hat Enterprise Linux 6.Red Hat Product Security has rated this update as having a security impact ofImportant.

A Common Vulnerability Scoring System (CVSS) base score, which givesa detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. The Simple Protocol for Independent Computing Environments (SPICE) is a remotedisplay protocol for virtual environments.
SPICE users can access a virtualizeddesktop or server from the local system or any system with network access to theserver.
SPICE is used in Red Hat Enterprise Linux for viewing virtualized guestsrunning on the Kernel-based Virtual Machine (KVM) hypervisor or on Red HatEnterprise Virtualization Hypervisors.Security Fix(es):* A memory allocation flaw, leading to a heap-based buffer overflow, was foundin spice's smartcard interaction, which runs under the QEMU-KVM context on thehost.

A user connecting to a guest VM using spice could potentially use thisflaw to crash the QEMU-KVM process or execute arbitrary code with the privilegesof the host's QEMU-KVM process. (CVE-2016-0749)* A memory access flaw was found in the way spice handled certain guests usingcrafted primary surface parameters.

A user in a guest could use this flaw toread from and write to arbitrary memory locations on the host. (CVE-2016-2150)The CVE-2016-0749 issue was discovered by Jing Zhao (Red Hat) and theCVE-2016-2150 issue was discovered by Frediano Ziglio (Red Hat). For details on how to apply this update, which includes the changes described inthis advisory, refer to:https://access.redhat.com/articles/11258Applications acting as a SPICE server must be restarted for this update to takeeffect. Note that QEMU-KVM guests providing SPICE console access must berestarted for this update to take effect.Red Hat Enterprise Linux Desktop (v. 6) SRPMS: spice-server-0.12.4-13.el6.1.src.rpm     MD5: b3f8e98369ffe2a12871cd096454d076SHA-256: d8bb9d53f30bfacd83374c41373aecf1f22b7a044e118905fc1fb820f95bf2c6   x86_64: spice-server-0.12.4-13.el6.1.x86_64.rpm     MD5: 14c5132e7ecc548d4127a1b9da1f0538SHA-256: 9dc528a7ff0e61ffe9504c2e633ece38c2c0f7656fbf6b5907195c07527ec737 spice-server-debuginfo-0.12.4-13.el6.1.x86_64.rpm     MD5: 9947e8c8707408bafe91ed327503ac5dSHA-256: 030067f06dc95f77a27d33428296c3e6febad54c3cf6cb5d3909d0da502ed9f5 spice-server-devel-0.12.4-13.el6.1.x86_64.rpm     MD5: 79d4a4d9c28a657b5df42c6424664255SHA-256: 5ca731677bebd967f6d9d356e37aeb822ee5202243c37eaa23249bd42d26c042   Red Hat Enterprise Linux HPC Node (v. 6) SRPMS: spice-server-0.12.4-13.el6.1.src.rpm     MD5: b3f8e98369ffe2a12871cd096454d076SHA-256: d8bb9d53f30bfacd83374c41373aecf1f22b7a044e118905fc1fb820f95bf2c6   x86_64: spice-server-0.12.4-13.el6.1.x86_64.rpm     MD5: 14c5132e7ecc548d4127a1b9da1f0538SHA-256: 9dc528a7ff0e61ffe9504c2e633ece38c2c0f7656fbf6b5907195c07527ec737 spice-server-debuginfo-0.12.4-13.el6.1.x86_64.rpm     MD5: 9947e8c8707408bafe91ed327503ac5dSHA-256: 030067f06dc95f77a27d33428296c3e6febad54c3cf6cb5d3909d0da502ed9f5 spice-server-devel-0.12.4-13.el6.1.x86_64.rpm     MD5: 79d4a4d9c28a657b5df42c6424664255SHA-256: 5ca731677bebd967f6d9d356e37aeb822ee5202243c37eaa23249bd42d26c042   Red Hat Enterprise Linux Server (v. 6) SRPMS: spice-server-0.12.4-13.el6.1.src.rpm     MD5: b3f8e98369ffe2a12871cd096454d076SHA-256: d8bb9d53f30bfacd83374c41373aecf1f22b7a044e118905fc1fb820f95bf2c6   x86_64: spice-server-0.12.4-13.el6.1.x86_64.rpm     MD5: 14c5132e7ecc548d4127a1b9da1f0538SHA-256: 9dc528a7ff0e61ffe9504c2e633ece38c2c0f7656fbf6b5907195c07527ec737 spice-server-debuginfo-0.12.4-13.el6.1.x86_64.rpm     MD5: 9947e8c8707408bafe91ed327503ac5dSHA-256: 030067f06dc95f77a27d33428296c3e6febad54c3cf6cb5d3909d0da502ed9f5 spice-server-devel-0.12.4-13.el6.1.x86_64.rpm     MD5: 79d4a4d9c28a657b5df42c6424664255SHA-256: 5ca731677bebd967f6d9d356e37aeb822ee5202243c37eaa23249bd42d26c042   Red Hat Enterprise Linux Workstation (v. 6) SRPMS: spice-server-0.12.4-13.el6.1.src.rpm     MD5: b3f8e98369ffe2a12871cd096454d076SHA-256: d8bb9d53f30bfacd83374c41373aecf1f22b7a044e118905fc1fb820f95bf2c6   x86_64: spice-server-0.12.4-13.el6.1.x86_64.rpm     MD5: 14c5132e7ecc548d4127a1b9da1f0538SHA-256: 9dc528a7ff0e61ffe9504c2e633ece38c2c0f7656fbf6b5907195c07527ec737 spice-server-debuginfo-0.12.4-13.el6.1.x86_64.rpm     MD5: 9947e8c8707408bafe91ed327503ac5dSHA-256: 030067f06dc95f77a27d33428296c3e6febad54c3cf6cb5d3909d0da502ed9f5 spice-server-devel-0.12.4-13.el6.1.x86_64.rpm     MD5: 79d4a4d9c28a657b5df42c6424664255SHA-256: 5ca731677bebd967f6d9d356e37aeb822ee5202243c37eaa23249bd42d26c042   (The unlinked packages above are only available from the Red Hat Network) These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from: