Transcript 01-chapman_maass_res..

Architecture Support for Security
Peter Chapman
Michael Maass
Overview
●
The Pervasiveness of Computing Vulnerabilities
●
Hardware vs. Software Mitigations
●
Hardware Challenges
●
Examples:
– Timing
– Code
Side Channels
Re-use Attacks
Overview
●
The Pervasiveness of Computing Vulnerabilities
●
Hardware vs. Software Mitigations
●
Hardware Challenges
●
Examples:
– Timing
– Code
Side Channels
Re-use Attacks
Ask Questions!
The Pervasiveness of Computing Vulnerabilities
●
Computing stacks are vulnerable at all layers
Software vulnerabilities are introduced at all
phases:
●
– Design/implementation
vulnerabilities
We'd like to catch vulnerabilities early, but we
don't always succeed
●
– Makes
the problem much harder and more
expensive
The Pervasiveness of Computing Vulnerabilities
Hardware is vulnerable for the same reasons as
software
– Hardware
is harder to fix because you can't
usually just patch it
– Sometimes
the vulnerability is due to physical
properties that are difficult to predict or model
The Pervasiveness of Computing Vulnerabilities
Hardware is vulnerable for the same reasons as
software
– Hardware
is harder to fix because you can't
usually just patch it
– Sometimes
the vulnerability is due to physical
properties that are difficult to predict or model
The Pervasiveness of Computing Vulnerabilities
The Pervasiveness of Computing Vulnerabilities
Is the server with
the HDL secure?
Overcoming an Untrusted Computing Base: Detecting and Removing Malicious Hardware Automatically
Hardware vs. Software Mitigations
Software is easier to deploy, but:
–
Some vulnerabilities can't easily be fixed in software due to
performance issues or a lack of context
–
Sometimes it's too expensive to fix in software because a general
solution doesn't exist
●
–
Every system needs a custom solution
Sometimes the solution works against the hardware
●
Tracking taint in at runtime consumes resources (e.g., cache,
registers, etc.)
Hardware Challenges
●
Needs very low overhead in terms of performance and space
Needs to be simple enough to reason about correctness while
still fixing the problem
●
●
Needs a very good reason to do it
If software support is necessary, adoption becomes more
expensive
●
●
Backwards compatibility is harder
●
Must avoid political landmines that harm adoption
–
TPM cooped by DRM
Timing Side Channels
Computations take varying lengths of time based on
the input and use different resources
●
– This
information leaks
Timing information can be correlated to statistically
determine private information such as key presses,
cryptographic keys, visited web sites, etc.
●
Timing Side Channels
We can deny access to timing information, thus
plugging the leak, but:
●
– Some
applications depend on accurate timing
information (e.g., games, multimedia, etc.)
– Denying
access still requires potentially
significant hardware/software changes
Bleach the timing data so that it's still monotonic, but
no longer allows for correlation
●
Code Reuse Attacks
Code injection attacks are
typically mitigated by
preventing existing code
from being changed or by
preventing data from
being executed as code
Attackers now make
clever use of existing
code
Code Reuse Attacks
In hardware:
–
Prevent jumps outside of the current function unless it's to the start
of a new function
–
Prevent calls to anything but the start of functions
–
Prevent return values from being changed
Need:
–
Hardware in the pipeline to perform checks on redirections
–
Software support is needed to securely mark the start of functions
–
A secure stack is required to prevent return values from being
changed
References
M. Kayaalp, M. Ozsoy, N. Abu-Ghazaleh, and D. Ponomarev, “Branch regulation: lowoverhead protection from code reuse attacks,” in Proceedings of the 39th International
Symposium on Computer Architecture, Piscataway, NJ, USA, 2012, pp. 94–105.
●
J. Valamehr, M. Chase, S. Kamara, A. Putnam, D. Shumow, V. Vaikuntanathan, and T.
Sherwood, “Inspection resistant memory: architectural support for security from physical
examination,” SIGARCH Comput. Archit. News, vol. 40, no. 3, pp. 130–141, Jun. 2012.
●
J. Demme, R. Martin, A. Waksman, and S. Sethumadhavan, “Side-channel vulnerability factor:
a metric for measuring information leakage,” SIGARCH Comput. Archit. News, vol. 40, no. 3,
pp. 106–117, Jun. 2012.
●
R. Martin, J. Demme, and S. Sethumadhavan, “TimeWarp: rethinking timekeeping and
performance monitoring mechanisms to mitigate side-channel attacks,” SIGARCH Comput.
Archit. News, vol. 40, no. 3, pp. 118–129, Jun. 2012.
●
S. Jana and V. Shmatikov, “Memento: Learning Secrets from Process Footprints,” in Security
and Privacy (SP), 2012 IEEE Symposium on, 2012, pp. 143 –157.
●