On platforms supporting simultaneous multi-threading (Hyper-Threading technology), local unprivileged users might be able to deduce potentially secret data from another executing thread, using cache eviction analysis techniques.

This issue is described in "Cache Missing for Fun and Profit" by Colin Percival, at http://www.daemonology.net/papers/htt.pdf.

This issue is referenced by CERT vulnerability note VU#911878 at http://www.kb.cert.org/vuls/id/911878 and CAN-2005-0109 at http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0109.

This issue can occur in the following releases:

x86 Platform

• Solaris 7
• Solaris 8
• Solaris 9
• Solaris 10

Notes:

1. This issue occurs only on processor platforms supporting simultaneous multi-threading (Hyper-Threading technology) with shared L1 caches.
2. Solaris on AMD Multi-Core processors is not affected by this issue.
3. Solaris on the SPARC platform is not affected by this issue.
4. While an exploit has been demonstrated in a controlled environment, this vulnerability requires local access. The victim thread's codepaths should be well understood by the attacker.

There are no predictable symptoms that would indicate the above described issue has been exploited.

Relief for this issue can be achieved by following methods:

A) Disabling Hyper-Threading in the BIOS:

Many BIOS implementations provide a way to disable the Hyper-Threading feature. With the feature disabled, threads will not be able to simultaneously execute on a given physical processor, thus closing the vulnerability.

Note: Overall system performance will likely be impacted.

OR:

B) Dynamic CPU Off-lining:

Solaris provides a mechanism allowing CPUs (including virtual on multi-threaded cores) to be taken off-line without rebooting. By taking virtual CPUs off-line, a multi-threaded (e.g. Hyper-Threaded) processor can be forced to support only one thread at a time. This restriction greatly reduces the ability of the spy to effectively monitor the victim by forcing context switching to occur between thread/processes. CPUs may be taken off-line with the psradm(1M) command.

Note: Overall system performance will likely be impacted, and these settings will not persist across reboot.

Example: Off-lining all but one of each physical processor's logical CPUs:

    # psrinfo -vp
    The physical processor has 2 virtual processors (0, 4)
      x86 (chipid 0x0 GenuineIntel family 15 model 2 step 6 clock 3000 MHz)
            Intel(r) Xeon(tm) MP CPU 3.00GHz
    The physical processor has 2 virtual processors (1, 5)
      x86 (chipid 0x1 GenuineIntel family 15 model 2 step 6 clock 3000 MHz)
            Intel(r) Xeon(tm) MP CPU 3.00GHz
    The physical processor has 2 virtual processors (2, 6)
      x86 (chipid 0x2 GenuineIntel family 15 model 2 step 6 clock 3000 MHz)
            Intel(r) Xeon(tm) MP CPU 3.00GHz
    The physical processor has 2 virtual processors (3, 7)
      x86 (chipid 0x3 GenuineIntel family 15 model 2 step 6 clock 3000 MHz)
            Intel(r) Xeon(tm) MP CPU 3.00GHz
    # psrinfo
    0       on-line   since 04/20/2005 17:13:16
    1       on-line   since 04/20/2005 17:13:21
    2       on-line   since 04/20/2005 17:13:23
    3       on-line   since 04/20/2005 17:13:25
    4       on-line   since 04/20/2005 17:13:27
    5       on-line   since 04/20/2005 17:13:29
    6       on-line   since 04/20/2005 17:13:31
    7       on-line   since 04/20/2005 17:13:33
    # psradm -f 4 5 6 7
    # psrinfo
    0       on-line   since 04/20/2005 17:13:16
    1       on-line   since 04/20/2005 17:13:21
    2       on-line   since 04/20/2005 17:13:23
    3       on-line   since 04/20/2005 17:13:25
    4       off-line  since 05/18/2005 11:05:07
    5       off-line  since 05/18/2005 11:05:07
    6       off-line  since 05/18/2005 11:05:07
    7       off-line  since 05/18/2005 11:05:07

Note: Availability of the psrinfo(1M) physical processor view (-vp) in Solaris 9 requires kernel patch 117172-17 or later. The feature is not available in Solaris 8 and earlier releases.

OR:

C) Solaris Containers:

Properly configured, the Containers feature in Solaris 10 can be used to close this vulnerability. Containers in Solaris consist of Resource Pools and Zones.

The Zones (zones(5)) feature allows for the creation of multiple virtual Solaris environments. Administrators can configure zones to contain users and applications. Each zone can then be bound to a CPU resource pool configured as above. Users and applications in a given zone will only be able to execute on CPUs contained in that zone's pool, thus preventing communication/spying across zones. It should be noted that proper use of Resource Pools to isolate CPU use of potential spy threads from processes containing valuable secret data (such as private keys) on the system could address this vulnerability. However, using Zones in addition to Resource Pools provides additional isolation since applications/users inside a given zone cannot see other applications/users outside the zone virtual environment.

Note: The above workaround applies only to systems with more than one physical processor.

Resource Pools are available in Solaris 9 as part of the built-in Solaris Resource Manager software. Zones and Resource Pools are both available in Solaris 10 as part of the built-in Solaris Containers feature.

For more information about using Zones, please visit the "Zones BigAdmin System Administration Portal" at http://www.sun.com/bigadmin/content/zones/

For more information about using Zones with Resource Pools, please see the "Solaris Containers Resource Management and Solaris Zones" answerbook at http://docs.sun.com/app/docs/doc/817-1592.

Workarounds described in the "Relief/Workaround" section are considered as the only practical methods to mitigate this issue.

01-Jun-2006:

• Updated Relief/Workaround

This solution has no attachment