Summary: | <app-emulation/xen-{4.2.3,4.3.1-r1} : multiple vulnerabilities (CVE-2013-{1442,4355,4356,4361,4368,4369,4370,4371,4375,4416,4494,4551,6375,6885}) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | idella4, xen |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.openwall.com/lists/oss-security/2013/09/25/2 | ||
Whiteboard: | B1 [glsa] | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 500530 | ||
Bug Blocks: |
Description
Agostino Sarubbo
2013-09-28 18:50:31 UTC
XSA 63 (CVE-2013-4355) : http://www.openwall.com/lists/oss-security/2013/09/30/1 XSA 64 (CVE-2013-4356) : http://www.openwall.com/lists/oss-security/2013/09/30/2 XSA 66 (CVE-2013-4361) : http://www.openwall.com/lists/oss-security/2013/09/30/3 CVE-2013-4361 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4361): The fbld instruction emulation in Xen 3.3.x through 4.3.x does not use the correct variable for the source effective address, which allows local HVM guests to obtain hypervisor stack information by reading the values used by the instruction. CVE-2013-4355 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4355): Xen 4.3.x and earlier does not properly handle certain errors, which allows local HVM guests to obtain hypervisor stack memory via a (1) port or (2) memory mapped I/O write or (3) other unspecified operations related to addresses without associated memory. CVE-2013-1442 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-1442): Xen 4.0 through 4.3.x, when using AVX or LWP capable CPUs, does not properly clear previous data from registers when using an XSAVE or XRSTOR to extend the state components of a saved or restored vCPU after touching other restored extended registers, which allows local guest OSes to obtain sensitive information by reading the registers. All these do pertain to app-emulation/xen. xen-4.3.0-r1 builds fine with the patches added. xen-4.2 stable misfires with the first patch listed, xsa62.patch, despite listing Xen 4.2.x. I've emailed the xen ML however stabilising 4.3-0-r1 will make the misfire redundant. There's the matter of the arm KEYWORD to correct first Ago. testuser@archtester ~/cvsPortage/gentoo-x86/app-emulation/xen $ ls /mnt/gen2/TmpDir/portage/app-emulation/xen-4.3.0-r1/work/xen-4.3.0//xen/arch/ yields arm x86. Seeing you can't boot a xen kernel in an arm proper, is it impossible then to EVER keyword xen arm? Otherwise I prompted you months ago to add it anyway. From memory I said building it in arm proper or emulator would suffice. XSA 67 (CVE-2013-4368) : http://www.openwall.com/lists/oss-security/2013/10/10/10 XSA 68 (CVE-2013-4369) : http://www.openwall.com/lists/oss-security/2013/10/10/11 XSA 69 (CVE-2013-4370) : http://www.openwall.com/lists/oss-security/2013/10/10/13 XSA 70 (CVE-2013-4371) : http://www.openwall.com/lists/oss-security/2013/10/10/12 XSA 71 (CVE-2013-4375) : http://www.openwall.com/lists/oss-security/2013/10/10/14 CVE-2013-4356 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4356): Xen 4.3.x writes hypervisor mappings to certain shadow pagetables when live migration is performed on hosts with more than 5TB of RAM, which allows local 64-bit PV guests to read or write to invalid memory and cause a denial of service (crash). CVE-2013-4371 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4371): Use-after-free vulnerability in the libxl_list_cpupool function in the libxl toolstack library in Xen 4.2.x and 4.3.x, when running "under memory pressure," returns the original pointer when the realloc function fails, which allows local users to cause a denial of service (heap corruption and crash) and possibly execute arbitrary code via unspecified vectors. CVE-2013-4370 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4370): The ocaml binding for the xc_vcpu_getaffinity function in Xen 4.2.x and 4.3.x frees certain memory that may still be intended for use, which allows local users to cause a denial of service (heap corruption and crash) and possibly execute arbitrary code via unspecified vectors that trigger a (1) use-after-free or (2) double free. CVE-2013-4369 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4369): The xlu_vif_parse_rate function in the libxlu library in Xen 4.2.x and 4.3.x allows local users to cause a denial of service (NULL pointer dereference) by using the "@" character as the VIF rate configuration. CVE-2013-4368 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4368): The outs instruction emulation in Xen 3.1.x, 4.2.x, 4.3.x, and earlier, when using FS: or GS: segment override, uses an uninitialized variable as a segment base, which allows local 64-bit PV guests to obtain sensitive information (hypervisor stack content) via unspecified vectors related to stale data in a segment register. XSA 72 (CVE-2013-4416) : http://seclists.org/oss-sec/2013/q4/187 XSA 73 : http://www.openwall.com/lists/oss-security/2013/11/01/2 (no cve) (In reply to Agostino Sarubbo from comment #9) > XSA 73 : http://www.openwall.com/lists/oss-security/2013/11/01/2 (no cve) CVE number was assigned, so, small fix XSA 73 (CVE-2013-4494) : http://www.openwall.com/lists/oss-security/2013/11/01/2 CVE-2013-4494 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4494): Xen before 4.1.x, 4.2.x, and 4.3.x does not take the page_alloc_lock and grant_table.lock in the same order, which allows local guest administrators with access to multiple vcpus to cause a denial of service (host deadlock) via unspecified vectors. CVE-2013-4416 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4416): The Ocaml xenstored implementation (oxenstored) in Xen 4.1.x, 4.2.x, and 4.3.x allows local guest domains to cause a denial of service (domain shutdown) via a large message reply. Added files/xen-CVE-2013-4368-XSA-67.patch, files/xen-CVE-2013-4375-XSA-71.patch, files/xen-CVE-2013-4494-XSA-73.patch since these pertain to app-emulation/xen, However, XSAs 68-70, 72 pertain to xen-tools, therefore it seems to me you either yet again edit the header title or whatever the right term is to incorporate app-emulation/xen-tools OR make a new sec. bug for the xsas cited above under xen-tools. Re 4.2, what a debacle. From the upstream maintainer, =============================================== It (xsa-62.patch) applies to 4.2-stable/staging. 2) Backport the xsave patches as well. http://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=xen/arch/x86/xstate.c;hb=12b0ee04a16194f064d5b895a844fcdc6414bfc0 should give you a good idea of the patches. http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=0bda88abe18029c2bbe9dc5d07cc706bd775c9b7 is probably the main patch needed. 3) Rework the security patch yourself using .... I highly recommend option 2. =============================================== So it seems there is xen-4.2 and xen-4.2/staging. Well to me one ought suffice. xsa patch 62 fails to take and & patch 63 fails to effect a build. Though I could attempt option 3) I'm really not naturally inclined. The version 4.2 therefore has not 1, not 2, but 3 issues. 1. The tarball of xen-4.2 appears to no longer suffice. ! !! ! 2. To counter this I need backport (or is it import) a number of separate patches. ! !! ! 3. Stable 4.2 appears it should not have been made stable by virtue of Bug 486076, exposing a dep on dev-lang/ocaml-4.x. The validity of Bug 486076 impacts on 4.3 which also requires >=dev-lang/ocaml-4. This makes stabalising of 4.3.x untenable until the 'fixing' of Bug 486076. I can make a xen-4.2.2-r2.ebuild IF YOU PROMPT with a 'yep go ahead'. It will have pertinent patches 64-73, given 62 & 63 DON'T WORK, with xsa71-qemu-xen-4.2.patch & xsa73-4.2.patch, otherwise, hang it. Re issue 2, I am open to suggestions as to how to manage it, otherwise, hang it. *xen-4.3.0-r2 (06 Nov 2013) 06 Nov 2013; Ian Delaney <idella4@gentoo.org> +files/xen-CVE-2013-4368-XSA-67.patch, +files/xen-CVE-2013-4375-XSA-71.patch, +files/xen-CVE-2013-4494-XSA-73.patch, +xen-4.3.0-r2.ebuild, xen-4.2.2-r1.ebuild, xen-4.3.0-r1.ebuild: Adding more security patches to 4.3.0 from Bug #486354, 4.2.2 excluded again for now XSA 75 (CVE-2013-4551) : http://seclists.org/oss-sec/2013/q4/249 XSA-78 (CVE-2013-6375) : http://www.openwall.com/lists/oss-security/2013/11/20/3 XSA 78 (CVE-2013-6375) : http://seclists.org/oss-sec/2013/q4/322 testuser@archtester ~/cvsPortage/gentoo-x86/app-emulation/xen $ USE="efi flask xsm" ebuild xen-4.3.0-r3.ebuild clean prepare install builds fine 4.2, is still a debacle. I have had no hints from comment 12, so it stays a debacle. The 4.3.0 is now updated. Once 4.3.0 is made stable 4.2 can be dropped off the portage map. 4.3 makes for a viable testing xen*. I asked you in irc inside a minute of your prompt if you'd care to pressure the maintainer of Bug 486076 into some action considering your activity deals totally with making ebuilds stable, and you gave NO reply. He's had just under a month to date. xen* stabilising is on hold until there is a stable form of ocaml-4 consequent to the resolution of Bug 486076 unless I totally misinterpret exchanges made in the virtualization channel in recent weeks. *xen-4.3.0-r3 (22 Nov 2013) 22 Nov 2013; Ian Delaney <idella4@gentoo.org> +files/xen-4.3-CVE-2013-6375-XSA-75.patch, +files/xen-CVE-2013-6375-XSA-78.patch, +xen-4.3.0-r3.ebuild, -xen-4.3.0-r1.ebuild, -xen-4.3.0-r2.ebuild, -xen-4.3.0.ebuild: Adding more security patches to 4.3.0 from Bug #486354, drop old XSA 82 (CVE-2013-6885) : http://seclists.org/oss-sec/2013/q4/385 "if you are able to do a rapid bump, I will do a fast stabilization" good luck with that. *xen-4.3.0-r4 (06 Dec 2013) *xen-4.3.1-r1 (06 Dec 2013) 06 Dec 2013; Ian Delaney <idella4@gentoo.org> +files/xen-CVE-2013-6885-XSA-82.patch, +xen-4.3.0-r4.ebuild, +xen-4.3.1-r1.ebuild, -xen-4.3.0-r3.ebuild, -xen-4.3.1.ebuild: revbumps; add sec XSA-82.patch, remove old USE ocaml has now been re-masked in or under profiles/eapi-5-files subsequent to prompting by dlan. Although far the less desired option, this makes xen* once again prone to be stabilised or is it stabilized. whatever. arch teams, excluding arm because it doesn't yet build, .... stabilise xen-4.3.1-r1.ebuild, xen-tools-4.3.1-r2, xen-pvgrub-4.3.1.ebuild. Change; revbump of xen-tools makes now for xen-tools-4.3.1-r3.ebuild amd64 stable x86 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one. glsa filed Ping! Maintainer(s), please drop the vulnerable version. fixed in xen-tools-4.2.3, xen-4.2.3 idella4 hilight me to specially mention that XSA-62, 63 has been solved, see bug #500530 for details Arches and Mainter(s), Thank you for your work. Added to an existing GLSA request. This issue was resolved and addressed in GLSA 201407-03 at http://security.gentoo.org/glsa/glsa-201407-03.xml by GLSA coordinator Mikle Kolyada (Zlogene). |