Impact of Spectre
117 views
Skip to first unread message
Adrian-Ken Rueegsegger
Jan 19, 2018, 11:15:22 AM1/19/18
to muen-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
We thoroughly studied the potential impact of the recent
Spectre/Meltdown speculative execution CPU design issues on the Muen
Separation Kernel. In this mail we would like to share our findings
regarding Spectre and our plans to address these issues. For the
technical details of the Spectre vulnerability the reader is directed to
the associated papers and blog posts [1][2][3].
Please note that the mail describes the current state of analysis which
may change when further information becomes available. Our assessment
with regards to Meltdown was sent to this list in a previous mail [4].
= tl;dr / Summary
Spectre opens up significant new attack avenues on most current IT
infrastructure. The Muen kernel is affected by Spectre (one indirect
jump in debug build, one indirect access after range check). The
observed issues can be fixed with small local changes and no
architectural modifications.
As Spectre relies on mechanisms which are also responsible for existing
side channel attacks, the specific design of the Muen Separation Kernel
adds significant obstacles and limitations to the exploitation of the
previously unknown vulnerabilities. Depending on the system
configuration, some attack scenarios can even be ruled out completely by
the Muen architecture.
= Introduction
Spectre is part of a new attack class which relies on observing side
effects caused by speculative instruction execution.
As speculative execution does not change the program state in case of a
mis-speculation, the attack is limited to observing indirect timing
effects caused by the speculation. In contrast to existing side channel
attacks, it may exploit instruction sequences which would otherwise not
be available to an attacker.
For a successful Spectre attack the following requirements have to be
met:
(1) Information availability:
The victim has access to the desired information.
(2) Code vulnerability:
The victim contains code vulnerable to a specific Spectre attack.
(3) Reachability:
The attacker can trigger the vulnerability.
Variant 1: The attacker can cause specifically crafted data to be
handled by the victim's code. (CVE-2017-5753)
Variant 2: The attacker can poison the Branch Prediction Cache and
redirect an indirect call/branch/return. (CVE-2017-5715)
Subvariant 2a: Branch Target Buffer (BTB)
Subvariant 2b: Return Stack Buffer (RSB)
(4) Indirect speculative execution effect:
The attacker is affected by the (indirect timing) effects of the
speculative execution.
(5) Time measurement:
The attacker can measure the timing effects induced by the attack.
As attacks can be directed against the Muen kernel or subjects there are
three classes of attack:
(A) Subject A -> Muen Kernel
The attacker attempts to obtain information from the Muen kernel
(B) Subject A -> Subject B
The attacker attempts to obtain information from another subject
(C) Subject A -> Subject A (Subject internal attack)
The attacker attempts to obtain information within the same
virtualized subject (e.g. Linux or Windows).
Scenario C must be analyzed and mitigated within the subject and is not
discussed further.
== Examined Version
The source code analysis was performed on the Muen devel branch with
revision e061946. Binary analysis was done on the kernel executable
compiled with the GNAT GPL 2017 compiler.
= Scenario A: Subject -> Kernel Attacks
== Requirement 1: Information Availability
Sensitive information present in the kernel is primarily limited to
subject register state of subjects running on the same CPU, as Muen has
no need to map subject memory or subject state belonging to other CPUs.
== Requirement 2: Code Vulnerability
=== Variant 1: Bounds Check Bypass
After analysis of the entire kernel source we identified three potential
avenues of attack in the code where only one actually matches the attack
pattern: Handle_Hypercall [5] receives the event number (0-31) in a 64
bit register from the calling subject. The issue was resolved by
extending the bounds check with a mask [6] which filters out invalid
values.
=== Variant 2a: Branch Target Injection (indirect jump/call)
The debug code contains one indirect jump in a string conversion
function [7]. No other indirect calls, indirect jumps or returns with
explicitly stored destinations were found.
Therefore we conclude that the release build of the Muen kernel is not
susceptible to this attack. We skip further analysis of the vulnerable
debug build.
=== Variant 2b: Branch Target Injection (return)
With current understanding, an attack against generic ret instructions
relying only on the Return Stack Buffer (RSB) is infeasible, as the
kernel has a deterministic and sufficiently shallow call sequence which
runs without interruptions (Assumption: shallow and symmetric call
sequence in SMM).
== Requirement 3: Reachability
=== Variant 1: Bounds Check Bypass
As the attacker can directly choose data sent to the vulnerable code, it
is highly likely that the flaw can be triggered in Handle_Hypercall
although this has not been verified experimentally.
== Requirement 4: Indirect Speculative Execution Effect
The attacker must be able to cause an effect visible to the attacker by
the code that is speculatively executed by the victim.
Currently published attacks rely on effects on the data channel which
depend on the attacker and the victim having access to common parts of
the cache. This is the case.
Selected other avenues are:
Translation Lookaside Buffer (TLB): The TLB is flushed on VMX
entry/exit. The VPID feature is not used on purpose.
Branch Prediction Cache (BPC): The BPC _should_ not be affected by
speculative execution since only successfully retired branches should be
recorded by the branch predictor.
Performance Counters: No access to performance counters or other tracing
facilities are provided to subjects.
Kernel Execution Time: When executing hypercalls the in-kernel execution
time affects the attackers alloted time budget.
== Requirement 5: Time Measurement
In order to reduce the capacity of side channels, high resolution timers
(e.g. Time Stamp Counter) are disabled by default. Only a virtualized
low-resolution (typically: ~1ms) timer is provided.
In addition subjects are intentionally restricted to one core which
prevents the obvious option for re-constructing a high resolution timer.
Note: Depending on the system configuration, assigned devices or
cooperating subjects running on a different CPU may provide a high
resolution timer.
= Scenario B: Subject -> Subject Attacks
== Requirement 1: Information Availability
Due to the strict isolation properties of Muen, critical information can
be assured to be limited to specific subjects which restricts the choice
of potential victims.
== Requirement 2: Code Vulnerability
For the purpose of this assessment we assume that the subject code is
vulnerable.
== Requirement 3: Reachability
=== Variant 1: Bounds Check Bypass
The attacker must be able to communicate chosen data to the victim.
This is only possible if a (potentially transitive) memory channel from
the attacker to the victim is configured by the system integrator.
=== Variant 2a: Branch Target Injection (indirect jump/call)
The attacker can only poison the Branch Target Buffer (BTB) when it is
running on the same CPU as the victim.
=== Variant 2b: Branch Target Injection (return)
The attacker may only reliably influence the next subject scheduled as
further execution will significantly affect the small RSB.
== Requirement 4: Indirect Speculative Execution Effect
The options for the attacker are similar to scenario A.
As additional difficulty, any effect from a victim subject not scheduled
in parallel must remain in existence until the attacker is scheduled
again in the next cycle.
Data Cache attacks can be avoided by implementing cache
partitioning/coloring as described in the Muen report, section 6.2.1
[8]. Note that although planned, this feature is not yet implemented.
== Requirement 5: Time Measurement
Time measurement is similarly restricted as in scenario A.
Compared to attacks against the kernel, having only one observation
option per scheduling cycle further reduces signal and increases noise.
= Evaluation & Conclusion
The Muen kernel is only affected by Spectre Variant 1 at a single
location. Subject-to-subject attacks are possible but severely limited
in their effectiveness by a combination of design properties of the
separation kernel:
- - Fixed cyclic scheduling
- - Static resource allocation
- - Strictly enforced data flows
- - Minimal permissions given to subjects
- - Avoidance of unneeded features (selection)
- No root-mode ring 3 subjects
- No Hyper-Threading
- No complex hypercalls
- - Denial of high precision timers to subjects
This reinforces our opinion that the focus on simplicity and minimality
for the kernel design and the usage of SPARK as implementation language
are a good way to build resilient systems which help reduce the impact
of yet unknown attack vectors.
Due to the small size of Muen, we were able to thoroughly review the
source code as well as the binary and quickly identify relevant
locations.
Since side channels are a well known subject we implemented mechanisms
that are generally applicable to this class of attacks. The design of
the scheduler in combination with the security policy applied by the
Mugenschedcfg tool [9] for generating scheduling plans can be leveraged
to significantly reduce or even avoid sharing of micro-architectural
state.
While the side channel avoidance features of Muen limit the effect of
Spectre, the remaining effectiveness of the attack depends on the policy
chosen by the system integrator. Of special importance is the denial of
precise timers to potential attackers and a careful configuration of
scheduling plans to assure spatial (same CPU) and temporal (same time)
isolation.
Nevertheless, the fact that one subject can potentially influence the
speculative execution paths of another subject is very unsatisfactory.
While it might be possible to develop trusted subjects with special care
to avoid problematic constructs, the goal of a separation kernel is to
guarantee isolation independent of the actual subject code.
We will take further steps and integrate additional defenses once it has
become clear which mitigations provided by hardware and compiler vendors
are effective and required to resolve the remaining issues.
Kind regards,
The Muen Team
[1] - https://spectreattack.com
[2] -
https://googleprojectzero.blogspot.ch/2018/01/reading-privileged-memory-
with-side.html
[3] -
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Ana
lysis-of-Speculative-Execution-Side-Channels.pdf
[4] - https://groups.google.com/forum/#!topic/muen-dev/1ILwIz8h-kM
[5] -
https://git.codelabs.ch/?p=muen.git;a=blob;f=kernel/src/sk-scheduler.adb
;h=67fe61f41125342405bbe02b4d18a301af11e03d;hb=e061946b1b55be046e2f68003
2f53d06ec861f23#l509
[6] -
https://git.codelabs.ch/?p=muen.git;a=commit;h=e4496482dd7aa41642bad1969
3714099f216c653
[7] -
https://git.codelabs.ch/?p=muen.git;a=blob;f=common/strings/impl/sk-stri
ngs.adb;h=f39fa002c0b04baf9fc9cb84b35d347442f00be8;hb=e061946b1b55be046e
2f680032f53d06ec861f23#l27
[8] - https://muen.codelabs.ch/muen-report.pdf
[9] - https://git.codelabs.ch/?p=muen/mugenschedcfg.git
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJaYhmWAAoJEMEf4lxkugAyNMIP/0Ea8Wa5n6cxNs3kf0nq8Dze
lerUt9qyOjQYkD6SWK9w+hPREtKIswOgZmOYTpMge3apFi3KcEB7q582lCmdkACk
tUfOQHFU2OKDXNQV1lbww7Q9lhr6n55+qaxW0ASJR0atnexsWEtLI5WfEsyml103
nH3hjx3YBkNOGVw5T3QdLz+2ZXDkWF+jJyvhYWiLtL38ETY8dsRjR7Rqup6+ygKr
LaRc73hjfcWnqlvZVS6tnFcORIjPEHw421MGJrBYYNFluoI+NHRYdSCd/NPyrj4O
/n8kUU29zxqXvSulHK9SSo6pauWFzp8P/Xg56zGpVlSlZg03BWFk7A5C8/rihIb/
mGdrzNDhQF+si3TF5BlETuLhLgqeUvlPByGIJfTgYPiMDY0J86IiUkItpl/BDPwo
6QjibUczT04vdyGRaiLqb4YDkt/YEzTWpiNfUchfd4NOVt0tHHJwM9FfOGw5C3/K
GJ8801yalP2KFY9pykWo+aSsNTLeM0L8nBJRFXClAJfM5r+62wPOJYgcALPFQn2y
SIkEEmuHprjrQkhWXzwfxnkWEczx1GQfYE5XT2VNhc6pOgCscl/37/I7V0KvNlxm
aJ0npBLux9/zmhNkCaoNJjwe1xOnQmSqC7QePDyKL+jY8edCFHoCWkmh+xUKtSzV
rVMJBfv3xtpcSWiBYeeK
=xoDJ
-----END PGP SIGNATURE-----
Hash: SHA256
Hi,
We thoroughly studied the potential impact of the recent
Spectre/Meltdown speculative execution CPU design issues on the Muen
Separation Kernel. In this mail we would like to share our findings
regarding Spectre and our plans to address these issues. For the
technical details of the Spectre vulnerability the reader is directed to
the associated papers and blog posts [1][2][3].
Please note that the mail describes the current state of analysis which
may change when further information becomes available. Our assessment
with regards to Meltdown was sent to this list in a previous mail [4].
= tl;dr / Summary
Spectre opens up significant new attack avenues on most current IT
infrastructure. The Muen kernel is affected by Spectre (one indirect
jump in debug build, one indirect access after range check). The
observed issues can be fixed with small local changes and no
architectural modifications.
As Spectre relies on mechanisms which are also responsible for existing
side channel attacks, the specific design of the Muen Separation Kernel
adds significant obstacles and limitations to the exploitation of the
previously unknown vulnerabilities. Depending on the system
configuration, some attack scenarios can even be ruled out completely by
the Muen architecture.
= Introduction
Spectre is part of a new attack class which relies on observing side
effects caused by speculative instruction execution.
As speculative execution does not change the program state in case of a
mis-speculation, the attack is limited to observing indirect timing
effects caused by the speculation. In contrast to existing side channel
attacks, it may exploit instruction sequences which would otherwise not
be available to an attacker.
For a successful Spectre attack the following requirements have to be
met:
(1) Information availability:
The victim has access to the desired information.
(2) Code vulnerability:
The victim contains code vulnerable to a specific Spectre attack.
(3) Reachability:
The attacker can trigger the vulnerability.
Variant 1: The attacker can cause specifically crafted data to be
handled by the victim's code. (CVE-2017-5753)
Variant 2: The attacker can poison the Branch Prediction Cache and
redirect an indirect call/branch/return. (CVE-2017-5715)
Subvariant 2a: Branch Target Buffer (BTB)
Subvariant 2b: Return Stack Buffer (RSB)
(4) Indirect speculative execution effect:
The attacker is affected by the (indirect timing) effects of the
speculative execution.
(5) Time measurement:
The attacker can measure the timing effects induced by the attack.
As attacks can be directed against the Muen kernel or subjects there are
three classes of attack:
(A) Subject A -> Muen Kernel
The attacker attempts to obtain information from the Muen kernel
(B) Subject A -> Subject B
The attacker attempts to obtain information from another subject
(C) Subject A -> Subject A (Subject internal attack)
The attacker attempts to obtain information within the same
virtualized subject (e.g. Linux or Windows).
Scenario C must be analyzed and mitigated within the subject and is not
discussed further.
== Examined Version
The source code analysis was performed on the Muen devel branch with
revision e061946. Binary analysis was done on the kernel executable
compiled with the GNAT GPL 2017 compiler.
= Scenario A: Subject -> Kernel Attacks
== Requirement 1: Information Availability
Sensitive information present in the kernel is primarily limited to
subject register state of subjects running on the same CPU, as Muen has
no need to map subject memory or subject state belonging to other CPUs.
== Requirement 2: Code Vulnerability
=== Variant 1: Bounds Check Bypass
After analysis of the entire kernel source we identified three potential
avenues of attack in the code where only one actually matches the attack
pattern: Handle_Hypercall [5] receives the event number (0-31) in a 64
bit register from the calling subject. The issue was resolved by
extending the bounds check with a mask [6] which filters out invalid
values.
=== Variant 2a: Branch Target Injection (indirect jump/call)
The debug code contains one indirect jump in a string conversion
function [7]. No other indirect calls, indirect jumps or returns with
explicitly stored destinations were found.
Therefore we conclude that the release build of the Muen kernel is not
susceptible to this attack. We skip further analysis of the vulnerable
debug build.
=== Variant 2b: Branch Target Injection (return)
With current understanding, an attack against generic ret instructions
relying only on the Return Stack Buffer (RSB) is infeasible, as the
kernel has a deterministic and sufficiently shallow call sequence which
runs without interruptions (Assumption: shallow and symmetric call
sequence in SMM).
== Requirement 3: Reachability
=== Variant 1: Bounds Check Bypass
As the attacker can directly choose data sent to the vulnerable code, it
is highly likely that the flaw can be triggered in Handle_Hypercall
although this has not been verified experimentally.
== Requirement 4: Indirect Speculative Execution Effect
The attacker must be able to cause an effect visible to the attacker by
the code that is speculatively executed by the victim.
Currently published attacks rely on effects on the data channel which
depend on the attacker and the victim having access to common parts of
the cache. This is the case.
Selected other avenues are:
Translation Lookaside Buffer (TLB): The TLB is flushed on VMX
entry/exit. The VPID feature is not used on purpose.
Branch Prediction Cache (BPC): The BPC _should_ not be affected by
speculative execution since only successfully retired branches should be
recorded by the branch predictor.
Performance Counters: No access to performance counters or other tracing
facilities are provided to subjects.
Kernel Execution Time: When executing hypercalls the in-kernel execution
time affects the attackers alloted time budget.
== Requirement 5: Time Measurement
In order to reduce the capacity of side channels, high resolution timers
(e.g. Time Stamp Counter) are disabled by default. Only a virtualized
low-resolution (typically: ~1ms) timer is provided.
In addition subjects are intentionally restricted to one core which
prevents the obvious option for re-constructing a high resolution timer.
Note: Depending on the system configuration, assigned devices or
cooperating subjects running on a different CPU may provide a high
resolution timer.
= Scenario B: Subject -> Subject Attacks
== Requirement 1: Information Availability
Due to the strict isolation properties of Muen, critical information can
be assured to be limited to specific subjects which restricts the choice
of potential victims.
== Requirement 2: Code Vulnerability
For the purpose of this assessment we assume that the subject code is
vulnerable.
== Requirement 3: Reachability
=== Variant 1: Bounds Check Bypass
The attacker must be able to communicate chosen data to the victim.
This is only possible if a (potentially transitive) memory channel from
the attacker to the victim is configured by the system integrator.
=== Variant 2a: Branch Target Injection (indirect jump/call)
The attacker can only poison the Branch Target Buffer (BTB) when it is
running on the same CPU as the victim.
=== Variant 2b: Branch Target Injection (return)
The attacker may only reliably influence the next subject scheduled as
further execution will significantly affect the small RSB.
== Requirement 4: Indirect Speculative Execution Effect
The options for the attacker are similar to scenario A.
As additional difficulty, any effect from a victim subject not scheduled
in parallel must remain in existence until the attacker is scheduled
again in the next cycle.
Data Cache attacks can be avoided by implementing cache
partitioning/coloring as described in the Muen report, section 6.2.1
[8]. Note that although planned, this feature is not yet implemented.
== Requirement 5: Time Measurement
Time measurement is similarly restricted as in scenario A.
Compared to attacks against the kernel, having only one observation
option per scheduling cycle further reduces signal and increases noise.
= Evaluation & Conclusion
The Muen kernel is only affected by Spectre Variant 1 at a single
location. Subject-to-subject attacks are possible but severely limited
in their effectiveness by a combination of design properties of the
separation kernel:
- - Fixed cyclic scheduling
- - Static resource allocation
- - Strictly enforced data flows
- - Minimal permissions given to subjects
- - Avoidance of unneeded features (selection)
- No root-mode ring 3 subjects
- No Hyper-Threading
- No complex hypercalls
- - Denial of high precision timers to subjects
This reinforces our opinion that the focus on simplicity and minimality
for the kernel design and the usage of SPARK as implementation language
are a good way to build resilient systems which help reduce the impact
of yet unknown attack vectors.
Due to the small size of Muen, we were able to thoroughly review the
source code as well as the binary and quickly identify relevant
locations.
Since side channels are a well known subject we implemented mechanisms
that are generally applicable to this class of attacks. The design of
the scheduler in combination with the security policy applied by the
Mugenschedcfg tool [9] for generating scheduling plans can be leveraged
to significantly reduce or even avoid sharing of micro-architectural
state.
While the side channel avoidance features of Muen limit the effect of
Spectre, the remaining effectiveness of the attack depends on the policy
chosen by the system integrator. Of special importance is the denial of
precise timers to potential attackers and a careful configuration of
scheduling plans to assure spatial (same CPU) and temporal (same time)
isolation.
Nevertheless, the fact that one subject can potentially influence the
speculative execution paths of another subject is very unsatisfactory.
While it might be possible to develop trusted subjects with special care
to avoid problematic constructs, the goal of a separation kernel is to
guarantee isolation independent of the actual subject code.
We will take further steps and integrate additional defenses once it has
become clear which mitigations provided by hardware and compiler vendors
are effective and required to resolve the remaining issues.
Kind regards,
The Muen Team
[1] - https://spectreattack.com
[2] -
https://googleprojectzero.blogspot.ch/2018/01/reading-privileged-memory-
with-side.html
[3] -
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Ana
lysis-of-Speculative-Execution-Side-Channels.pdf
[4] - https://groups.google.com/forum/#!topic/muen-dev/1ILwIz8h-kM
[5] -
https://git.codelabs.ch/?p=muen.git;a=blob;f=kernel/src/sk-scheduler.adb
;h=67fe61f41125342405bbe02b4d18a301af11e03d;hb=e061946b1b55be046e2f68003
2f53d06ec861f23#l509
[6] -
https://git.codelabs.ch/?p=muen.git;a=commit;h=e4496482dd7aa41642bad1969
3714099f216c653
[7] -
https://git.codelabs.ch/?p=muen.git;a=blob;f=common/strings/impl/sk-stri
ngs.adb;h=f39fa002c0b04baf9fc9cb84b35d347442f00be8;hb=e061946b1b55be046e
2f680032f53d06ec861f23#l27
[8] - https://muen.codelabs.ch/muen-report.pdf
[9] - https://git.codelabs.ch/?p=muen/mugenschedcfg.git
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJaYhmWAAoJEMEf4lxkugAyNMIP/0Ea8Wa5n6cxNs3kf0nq8Dze
lerUt9qyOjQYkD6SWK9w+hPREtKIswOgZmOYTpMge3apFi3KcEB7q582lCmdkACk
tUfOQHFU2OKDXNQV1lbww7Q9lhr6n55+qaxW0ASJR0atnexsWEtLI5WfEsyml103
nH3hjx3YBkNOGVw5T3QdLz+2ZXDkWF+jJyvhYWiLtL38ETY8dsRjR7Rqup6+ygKr
LaRc73hjfcWnqlvZVS6tnFcORIjPEHw421MGJrBYYNFluoI+NHRYdSCd/NPyrj4O
/n8kUU29zxqXvSulHK9SSo6pauWFzp8P/Xg56zGpVlSlZg03BWFk7A5C8/rihIb/
mGdrzNDhQF+si3TF5BlETuLhLgqeUvlPByGIJfTgYPiMDY0J86IiUkItpl/BDPwo
6QjibUczT04vdyGRaiLqb4YDkt/YEzTWpiNfUchfd4NOVt0tHHJwM9FfOGw5C3/K
GJ8801yalP2KFY9pykWo+aSsNTLeM0L8nBJRFXClAJfM5r+62wPOJYgcALPFQn2y
SIkEEmuHprjrQkhWXzwfxnkWEczx1GQfYE5XT2VNhc6pOgCscl/37/I7V0KvNlxm
aJ0npBLux9/zmhNkCaoNJjwe1xOnQmSqC7QePDyKL+jY8edCFHoCWkmh+xUKtSzV
rVMJBfv3xtpcSWiBYeeK
=xoDJ
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages