From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xen.org security team Subject: DRAFT XSA 142 - libxl fails to honour readonly flag on disks with qemu-xen Date: Tue, 15 Sep 2015 16:22:34 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Zbt0O-0003o4-NC for xen-devel@lists.xenproject.org; Tue, 15 Sep 2015 16:22:52 +0000 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com, m.a.young@durham.ac.uk, xen-devel@lists.xenproject.org Cc: "Xen.org security team" List-Id: xen-devel@lists.xenproject.org --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit ***** DRAFT DRAFT DRAFT ***** Xen Security Advisory XSA-142 libxl fails to honour readonly flag on disks with qemu-xen ISSUE DESCRIPTION ================= Callers of libxl can specify that a disk should be read-only to the guest. However, there is no code in libxl to pass this information to qemu-xen (the upstream-based qemu); and indeed there is no way in qemu to make a disk read-only. The vulnerability is exploitable only via devices emulated by the device model, not the parallel PV devices for supporting PVHVM. Normally the PVHVM device unplug protocol renders the emulated devices inaccessible early in boot. IMPACT ====== Malicious guest administrators or (in some situations) users may be able to write to supposedly read-only disk images. CDROM devices (that is, devices specified to be presented to the guest as CDROMs, regardless of the nature of the backing storage on the host) are not affected. VULNERABLE SYSTEMS ================== Only systems using qemu-xen (rather than qemu-xen-traditional) as the device model version are vulnerable. Only systems using libxl or libxl-based toolstacks are vulnerable. (This includes libvirt with the libxl driver.) All versions of libxl which support qemu-xen are vulnerable. Support for qemu-xen was introduced in Xen 4.1. If the host and guest together usually support PVHVM, the issue is exploitable only if the malicious guest administrator has control of the guest kernel or guest kernel command line. MITIGATION ========== Switching to qemu-xen-traditional will avoid this vulnerability. This can be done with device_model_version="qemu-xen-traditional" in the xl configuration file. Using stub domain device models (which necessarily involves switching to qemu-xen-traditional) will also avoid this vulnerability. This can be done with device_model_stubdomain_override=true in the xl configuration file. Either of these mitigations is liable to have other guest-visible effects or even regressions. It may be possible, depending on the configuration, to make the underlying storage object readonly, or to make it reject writes. RESOLUTION ========== There is no reasonable resolution because Qemu does not (at the time of writing) support presenting a read-only block device to a guest as a disk. The attached patch corrects the weakness in the libxl code, by rejecting the unsupported configurations, rather than allowing them to run but with the device perhaps writeable by the guest. Applying it should increase confidence and avoid future configuration errors, but will break configurations specifying read-only disk devices. xsa142.patch Xen 4.3.x and later $ sha256sum xsa142*.patch de0d6d19becac199037dce5a6a49e35cb7de5c99b8e2950600ed71fdc2d5a752 xsa142.patch $ NOTE REGARDING LACK OF EMBARGO ============================== This issue was discussed in public in the Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1257893 CREDITS ======= Thanks to Michael Young of Durham University for bring this problem to our attention. --=separator Content-Type: application/octet-stream; name="xsa142.patch" Content-Disposition: attachment; filename="xsa142.patch" Content-Transfer-Encoding: base64 RnJvbTogU3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5vLnN0YWJlbGxpbmlA ZXUuY2l0cml4LmNvbT4KVG86IDx4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVj dC5vcmc+CkNDOiA8d2VpLmxpdTJAY2l0cml4LmNvbT4sIDxJYW4uQ2FtcGJl bGxAZXUuY2l0cml4LmNvbT4sCgk8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNp dHJpeC5jb20+LCA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT4sCgk8bS5h LnlvdW5nQGR1cmhhbS5hYy51az4KU3ViamVjdDogW1BBVENIIHYyIGZvci00 LjZdIGxpYnhsOiBoYW5kbGUgcmVhZC1vbmx5IGRyaXZlcyB3aXRoIHFlbXUt eGVuCkRhdGU6IFR1ZSwgMTUgU2VwIDIwMTUgMTA6NTI6MTQgKzAxMDAKClRo ZSBjdXJyZW50IGxpYnhsIGNvZGUgZG9lc24ndCBkZWFsIHdpdGggcmVhZC1v bmx5IGRyaXZlcyBhdCBhbGwuCgpVcHN0cmVhbSBRRU1VIGFuZCBxZW11LXhl biBvbmx5IHN1cHBvcnQgcmVhZC1vbmx5IGNkcm9tIGRyaXZlczogbWFrZQpz dXJlIHRvIHNwZWNpZnkgInJlYWRvbmx5PW9uIiBmb3IgY2Ryb20gZHJpdmVz IGFuZCByZXR1cm4gZXJyb3IgaW4gY2FzZQp0aGUgdXNlciByZXF1ZXN0ZWQg YSBub24tY2Ryb20gcmVhZC1vbmx5IGRyaXZlLgoKVGhpcyBpcyBYU0EtMTQy LCBkaXNjb3ZlcmVkIGJ5IExpbiBMaXUKKGh0dHBzOi8vYnVnemlsbGEucmVk aGF0LmNvbS9zaG93X2J1Zy5jZ2k/aWQ9MTI1Nzg5MykuCgpTaWduZWQtb2Zm LWJ5OiBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBl dS5jaXRyaXguY29tPgotLS0KIHRvb2xzL2xpYnhsL2xpYnhsX2RtLmMgfCAg IDEzICsrKysrKysrKy0tLS0KIDEgZmlsZSBjaGFuZ2VkLCA5IGluc2VydGlv bnMoKyksIDQgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvdG9vbHMvbGli eGwvbGlieGxfZG0uYyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RtLmMKaW5kZXgg MDJjMDE2Mi4uNDY4ZmY5YyAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGli eGxfZG0uYworKysgYi90b29scy9saWJ4bC9saWJ4bF9kbS5jCkBAIC0xMTEw LDEzICsxMTEwLDE4IEBAIHN0YXRpYyBpbnQgbGlieGxfX2J1aWxkX2Rldmlj ZV9tb2RlbF9hcmdzX25ldyhsaWJ4bF9fZ2MgKmdjLAogICAgICAgICAgICAg aWYgKGRpc2tzW2ldLmlzX2Nkcm9tKSB7CiAgICAgICAgICAgICAgICAgaWYg KGRpc2tzW2ldLmZvcm1hdCA9PSBMSUJYTF9ESVNLX0ZPUk1BVF9FTVBUWSkK ICAgICAgICAgICAgICAgICAgICAgZHJpdmUgPSBsaWJ4bF9fc3ByaW50Zgot ICAgICAgICAgICAgICAgICAgICAgICAgKGdjLCAiaWY9aWRlLGluZGV4PSVk LG1lZGlhPWNkcm9tLGNhY2hlPXdyaXRlYmFjayxpZD1pZGUtJWkiLAotICAg ICAgICAgICAgICAgICAgICAgICAgIGRpc2ssIGRldl9udW1iZXIpOworICAg ICAgICAgICAgICAgICAgICAgICAgKGdjLCAiaWY9aWRlLGluZGV4PSVkLHJl YWRvbmx5PSVzLG1lZGlhPWNkcm9tLGNhY2hlPXdyaXRlYmFjayxpZD1pZGUt JWkiLAorICAgICAgICAgICAgICAgICAgICAgICAgIGRpc2ssIGRpc2tzW2ld LnJlYWR3cml0ZSA/ICJvZmYiIDogIm9uIiwgZGV2X251bWJlcik7CiAgICAg ICAgICAgICAgICAgZWxzZQogICAgICAgICAgICAgICAgICAgICBkcml2ZSA9 IGxpYnhsX19zcHJpbnRmCi0gICAgICAgICAgICAgICAgICAgICAgICAoZ2Ms ICJmaWxlPSVzLGlmPWlkZSxpbmRleD0lZCxtZWRpYT1jZHJvbSxmb3JtYXQ9 JXMsY2FjaGU9d3JpdGViYWNrLGlkPWlkZS0laSIsCi0gICAgICAgICAgICAg ICAgICAgICAgICAgZGlza3NbaV0ucGRldl9wYXRoLCBkaXNrLCBmb3JtYXQs IGRldl9udW1iZXIpOworICAgICAgICAgICAgICAgICAgICAgICAgKGdjLCAi ZmlsZT0lcyxpZj1pZGUsaW5kZXg9JWQscmVhZG9ubHk9JXMsbWVkaWE9Y2Ry b20sZm9ybWF0PSVzLGNhY2hlPXdyaXRlYmFjayxpZD1pZGUtJWkiLAorICAg ICAgICAgICAgICAgICAgICAgICAgIGRpc2tzW2ldLnBkZXZfcGF0aCwgZGlz aywgZGlza3NbaV0ucmVhZHdyaXRlID8gIm9mZiIgOiAib24iLCBmb3JtYXQs IGRldl9udW1iZXIpOwogICAgICAgICAgICAgfSBlbHNlIHsKKyAgICAgICAg ICAgICAgICBpZiAoIWRpc2tzW2ldLnJlYWR3cml0ZSkgeworICAgICAgICAg ICAgICAgICAgICBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwg InFlbXUteGVuIGRvZXNuJ3Qgc3VwcG9ydCByZWFkLW9ubHkgZGlzayBkcml2 ZXJzIik7CisgICAgICAgICAgICAgICAgICAgIHJldHVybiBFUlJPUl9JTlZB TDsKKyAgICAgICAgICAgICAgICB9CisKICAgICAgICAgICAgICAgICBpZiAo ZGlza3NbaV0uZm9ybWF0ID09IExJQlhMX0RJU0tfRk9STUFUX0VNUFRZKSB7 CiAgICAgICAgICAgICAgICAgICAgIExJQlhMX19MT0coY3R4LCBMSUJYTF9f TE9HX1dBUk5JTkcsICJjYW5ub3Qgc3VwcG9ydCIKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAiIGVtcHR5IGRpc2sgZm9ybWF0IGZvciAlcyIs IGRpc2tzW2ldLnZkZXYpOwotLSAKMS43LjEwLjQK --=separator Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=separator--