Date: 06 July 2012
References: ESB-2012.0538 ESB-2012.0541 ESB-2012.0542 ESB-2012.0546.2 ESB-2012.0694
Click here for printable version
Click here for PGP verifiable version
-----BEGIN PGP SIGNED MESSAGE-----
AUSCERT External Security Bulletin Redistribution
Intel processors sysret to non-canonical address behaviour
6 July 2012
AusCERT Security Bulletin Summary
Operating System: NetBSD
Impact/Access: Execute Arbitrary Code/Commands -- Existing Account
Denial of Service -- Existing Account
CVE Names: CVE-2012-0217
Revision History: July 6 2012: Updated severity after an exploit could be produced
June 15 2012: Initial Release
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
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, 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.
On Intel CPUs, the sysret instruction can be manipulated into returning
to specific non-canonical addresses, which may yield a CPU reset.
It has been shown by the VUPEN team that this vulnerability can also be
used to execute code with kernel privilege instead of crashing the system.
This vulnerability has been assigned CVE-2012-0217.
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
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 or execute attacker controlled code.
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.
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.
Additional thanks to the VUPEN team for showing how to exploit this
vulnerability to execute code under NetBSD and to Sofian Brabez for
pointing it out.
2012-06-14 Initial release
2012-07-06 Updated severity after an exploit could be produced
Advisories may be updated as new information becomes available.
The most recent version of this advisory (PGP signed) can be found at
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.
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
- -----END PGP SIGNATURE-----
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to firstname.lastname@example.org
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
Australian Computer Emergency Response Team
The University of Queensland
Internet Email: email@example.com
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----