Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
NetBSD Security Advisory 2018-005: Privilege separation bug in Xen-amd64
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NetBSD Security Advisory 2018-005
=================================
Topic: Privilege separation bug in Xen-amd64
Version: NetBSD-current: source prior to Sun, Dec 31st 2017
NetBSD 7.1.2: not affected
NetBSD 7.1 - 7.1.1: affected
NetBSD 7.0 - 7.0.2: affected
NetBSD 6.1 - 6.1.5: affected
NetBSD 6.0 - 6.0.6: affected
Severity: Privilege escalation / Local DoS
Fixed: NetBSD-current: Sun, Dec 31st 2017
NetBSD-7-1 branch: Mon, Jan 22nd 2018
NetBSD-7-0 branch: Mon, Jan 22nd 2018
NetBSD-7 branch: Mon, Jan 22nd 2018
NetBSD-6-1 branch: Mon, Feb 19th 2018
NetBSD-6-0 branch: Mon, Feb 19th 2018
NetBSD-6 branch: Mon, Feb 19th 2018
Teeny versions released later than the fix date will contain the fix.
Please note that NetBSD releases prior to 6.0 are no longer supported.
It is recommended that all users upgrade to a supported release.
Abstract
========
A mistake the Xen-amd64 port of NetBSD allowed unprivileged users to
read from and write to the CPU's I/O ports. This could be used to
escalate privileges.
Technical Details
=================
The kernel uses several flags that define CPU protections, and in particular,
SEL_KPL and SEL_UPL, that respectively define "kernel" privileges and "user"
privileges in the %cs register.
64bit Xen PV guests run, by design, in ring3, the same protection level as
userland. As a result, SEL_KPL equals SEL_UPL.
Xen uses a specific iopl privilege mechanism to control access rights to
the CPU I/O ports: it expects the iopl value to match the intended privilege,
and not the hardware privilege. Therefore, if the kernel wanted to prevent
userland from accessing the CPU I/O ports, it had to set the iopl to ring0,
even if the kernel actually runs in ring3.
A mistake existed in NetBSD, where iopl was unintentionally set to ring3,
allowing userland to access CPU I/O ports. The mistake in question was a
confusion with the privilege flags: iopl was set to SEL_KPL, but in the case
of Xen-amd64 this was equal to SEL_UPL, which meant ring3.
Solutions and Workarounds
=========================
For all NetBSD versions, you need to obtain fixed kernel sources,
rebuild and install the new kernel, and reboot the system.
The fixed source may be obtained from the NetBSD CVS repository.
The following instructions briefly summarize how to upgrade your
kernel. In these instructions, replace:
ARCH with your architecture (from uname -m),
KERNCONF with the name of your kernel configuration file and
VERSION with the file version below
File versions containing the fixes:
FILE HEAD netbsd-7 netbsd-7-0 netbsd-7-1
---- ---- -------- ---------- ----------
src/sys/arch/amd64/amd64/machdep.c
1.280 1.211.2.2 1.211.6.2 1.211.10.2
src/sys/arch/amd64/include/segments.h
1.34 1.24.12.1 1.24.16.1 1.24.22.1
src/sys/arch/i386/i386/machdep.c
1.800 1.752.4.2 1.752.8.2 1.752.12.2
src/sys/arch/i386/include/segments.h
1.64 1.54.30.1 1.54.34.1 1.54.38.1
src/sys/arch/x86/x86/vm_machdep.c
1.30 1.25.4.2 1.25.8.2 1.25.4.1.2.1
FILE netbsd-6 netbsd-6-0 netbsd-6-1
---- -------- ---------- ----------
src/sys/arch/amd64/amd64/machdep.c
1.175.2.10 1.175.2.7.2.3 1.175.2.8.2.2
src/sys/arch/amd64/include/segments.h
1.22.10.1 1.22.14.1 1.22.16.1
src/sys/arch/i386/i386/machdep.c
1.717.2.9 1.717.2.7.4.2 1.717.2.7.6.2
src/sys/arch/i386/include/segments.h
1.54.10.1 1.54.16.1 1.54.24.1
src/sys/arch/x86/x86/vm_machdep.c
1.14.2.1 1.14.6.1 1.14.8.1
To update from CVS, re-build, and re-install the kernel:
# cd src
# cvs update -d -P -r VERSION sys/arch/amd64/amd64/machdep.c
# cvs update -d -P -r VERSION sys/arch/amd64/include/segments.h
# cvs update -d -P -r VERSION sys/arch/i386/i386/machdep.c
# cvs update -d -P -r VERSION sys/arch/i386/include/segments.h
# cvs update -d -P -r VERSION sys/arch/x86/x86/vm_machdep.c
# ./build.sh kernel=KERNCONF
# mv /netbsd /netbsd.old
# cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd
# shutdown -r now
For more information on how to do this, see:
http://www.NetBSD.org/guide/en/chap-kernel.html
Thanks To
=========
Maxime Villard for finding and fixing the issue.
Revision History
================
2018-04-09 Initial release
More Information
================
Advisories may be updated as new information becomes available.
The most recent version of this advisory (PGP signed) can be found at
http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2018-005.txt.asc
Information about NetBSD and NetBSD security can be found at
http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ .
Copyright 2018, The NetBSD Foundation, Inc. All Rights Reserved.
Redistribution permitted only in full, unmodified form.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJay9YPAAoJEAZJc6xMSnBuvvkP/i++oukmYnYwveWd20jYIQ7r
/6K5FrdfslPkk8Wk0Rm8MV5QlPkp+aouJ/id/3ywQ7QoUx8qQOITo3yjTrVGqKkK
ksF2I5JLh+VwrOr4sitvanRST2b7FN6XqLL+UZf5aQg70ck/pobrI2nnH03Cs18I
snDno1hIly4WnBTu7H4+LvlUPgr+Ta6Ipix7/EwpQPKY6NImYG+LEIX8sEAe3D/e
RDyXV0O7/H6sf6cUmO4mNCnt1SbjblkS2LBMvYgrmrAWY5K6P93KYnQJ3HfIGwac
xM9FrQveZ2FYfoVx/OhIAmLrQXKTUde/YRhwwS8uyz4WLwaI1K31YjrVs6I2lcXn
K8AhGLzhHYr7d/UO9KgNufHlWtR1KEuqEj0LLOk3gFONmHkE37isZ6vnCR4+J3Ol
aVWGzd53pOxAz4i4e7KFfEDd91Xfxex1A561A6S7HGJtiTZX9UdvXraIU7/srC32
TjLbR7tHbiGm8O5Ajj9AvbCYaEcHaRNF6BImzz5SlZSsov9alCMuiotswgucyTkF
yu8rObLYJTGhNKHPrqMAN18jGQn9pap+KyT+DMcsDLQxtqEzuoqaSU6pSS76vt2E
bUb+RFhELRFCYjUr+UfWhCLRXlyK/2d6p7t3NAra0b0EVWQ0CoRSwEXwYKq76I8E
Lqk8n1FjrRmAqthVEqHi
=pr1D
-----END PGP SIGNATURE-----
Home |
Main Index |
Thread Index |
Old Index