NetBSD Security Advisory 2012-003: Intel processors sysret to non-canonical address behaviour

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

		NetBSD Security Advisory 2012-003
		=================================

Topic:		Intel processors sysret to non-canonical address behaviour


Version:	NetBSD-current:		source prior to June 11, 2012
		NetBSD 6.0 Beta:	affected
		NetBSD 5.1.*:		affected
		NetBSD 5.1:		affected
		NetBSD 5.0.*:		affected
		NetBSD 5.0:		affected
		NetBSD 4.0.*:		affected
		NetBSD 4.0:		affected

Severity:	local DoS, possibly local user privilege escalation

Fixed:		NetBSD-current:		June 12th, 2012
		NetBSD-6 branch:	June 12th, 2012
		NetBSD-5 branch:	June 12th, 2012
		NetBSD-5-1 branch:	June 12th, 2012
		NetBSD-5-0 branch:	June 12th, 2012
		NetBSD-4 branch:	June 12th, 2012
		NetBSD-4-0 branch:	June 12th, 2012

Please note that NetBSD releases prior to 4.0 are no longer supported.
It is recommended that all users upgrade to a supported release.


Abstract
========

On Intel CPUs, the sysret instruction can be manipulated into returning 
to specific non-canonical addresses, which may yield a CPU reset.
We cannot currently rule out with utter confidence that this vulnerability
could not also be used to execute code with kernel privilege instead
of crashing the system.

This vulnerability has been assigned CVE-2012-0217.


Technical Details
=================

This is a vulnerability following from a difference of behaviour of
sysret in Intel's version of the amd64 architecture, em64t.

System calls may be implemented as using the em64t syscall/sysret
instruction pair.

syscall saves the context of the calling unprivileged process before
executing a system call in kernel mode; sysret restores it and resumes
ordinary operations in user mode.

In the Intel implementation of sysret, if you have invalid information
about the "next instruction" address in your saved context, the sysret
instruction will trigger a trap in kernel space. However the sysret
instruction is executed with the user stack pointer already loaded,
so the kernel fault frame is written to the user stack.
The kernel is unable to safely recover from this, so must ensure
that the trap doesn't happen.

If your invalid "next instruction" address is in kernel space or
in user space (and in the latter case, not where your program is)
the program will segfault.
If it is in the gap between user space and kernel space, the CPU
will reset, except if someone managed to seed the address location
with a valid instruction.


Solutions and Workarounds
=========================

The fix in the following versions will disallow sysret to
an invalid address.

src/sys/arch/amd64/amd64/machdep.c
HEAD		1.184
netbsd-6	1.175.2.6
netbsd-5	1.102.4.14
netbsd-5-1	1.102.4.13.2.1
netbsd-5-0	1.102.4.10.2.2
netbsd-4	1.44.2.7
netbsd-4-0	1.44.2.3.6.1

src/sys/arch/amd64/amd64/netbsd32_machdep.c
HEAD		1.77
netbsd-6	1.74.10.2
netbsd-5	1.55.4.4
netbsd-5-1	1.55.4.3.2.1
netbsd-5-0	1.55.6.3
netbsd-4	1.30.2.4
netbsd-4-0	1.30.2.1.6.1


Thanks To
=========

Thanks to Manuel Bouyer for providing the fix, and David Laight for
help with writing the advisory. Also, thanks to Rafal Wojtczuk for
bringing the issue to our attention.


Revision History
================

	2012-06-14	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-SA2012-003.txt.asc

Information about NetBSD and NetBSD security can be found at
http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ .


Copyright 2012, The NetBSD Foundation, Inc.  All Rights Reserved.
Redistribution permitted only in full, unmodified form.

$NetBSD $

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJP2aqNAAoJEAZJc6xMSnBulJcQAIUhFdoKg2S68lthVzENVeRC
L5SqqrjWOcIXLDrzSimqPBWCtX5ucTgH1q3GXjkDYPJpmPfAE4VBR4PbtenPB2vB
JCm6DUzY3KiUxnIn/5hDFzol1vXlPX5l+0s3mhdcMIxg8NDIeqqHw+4xj4e6jkW3
9lcUn/1OpRWWDXxd6UnN4S0v7tGxdjaqh5ZeaNZNTCaRfriDAzQyqobBFs91kWkS
bfX1h1pcpM+qM19IZRLHdrQRdrcyJmCrCD6pWQcVUaZyXHK9EjkzSbpuzSTu//QB
rPXv+SZ1Pg4GE7a4KMEKZen+tWdNbzxzehoRC6/uJswk1vaCByGkE+a4Upe9FzGJ
eXYO7T0Fkk4jsrfOEBn2CPzL8l3RVdMv3W7KhcfKkKNW7uIiaM0ltay1k4vVAMiE
2szUFonzkc9VAFTdn+FX3sRUi/mstddsf1KZQVksRXonoDXjp3Rwv+RVI7i0iTCm
Rre2t9gRFTZNLh/a1UBUTuRL4lzYgh9DF4uUbzxHI/PJYdYLBZZAtQIuJHvW8Poi
08H7aK1Pz24CdyG2R5sWfgIaITid3WHKyoOy9r4osZq16i2zWioNxdsTAcWRLyJL
edChEVo2KD3JDJT1W/oi+9PXkGlZKDk6yRYxBxf0TmTQzwmwruH7ryDgZ3lr+uft
fnyEquQngEkE9xiOgmMR
=c6FC
-----END PGP SIGNATURE-----