Derrick Paul McKee

dblp:210/2383 · DBLP profile ↗
← Back
5ranked-venue papers
1as first author
2since 2021 · last 2022
0000-0003-2357-7139ORCID · reported

Domains — the database's venue-derived domains; a paper can count in several

Security and privacy · 4 · 1 first-author · 2 since 2021Systems, architecture and hardware · 1
YearPublicationVenuePosition
2022 Preventing Kernel Hacks with HAKCs
Derrick Paul McKee, Yianni Giannaris, Carolina Ortega, Howard E. Shrobe, Mathias Payer, Hamed Okhravi, Nathan Burow
NDSS1
2021 μSCOPE: A Methodology for Analyzing Least-Privilege Compartmentalization in Large Software Artifacts
abstract
By prioritizing simplicity and portability, least-privilege engineering has been an afterthought in OS design, resulting in monolithic kernels where any exploit leads to total compromise. μSCOPE (“microscope”) addresses this problem by automatically identifying opportunities for least-privilege separation. μSCOPE replaces expert-driven, semi-automated analysis with a general methodology for exploring a continuum of security vs. performance design points by adopting a quantitative and systematic approach to privilege analysis. We apply the μSCOPE methodology to the Linux kernel by (1) instrumenting the entire kernel to gain comprehensive, fine-grained memory access and call activity; (2) mapping these accesses to semantic information; and (3) conducting separability analysis on the kernel using both quantitative privilege and overhead metrics. We discover opportunities for orders of magnitude privilege reduction while predicting relatively low overheads—at 15% mediation overhead, overprivilege in Linux can be reduced up to 99.8%—suggesting fine-grained privilege separation is feasible and laying the groundwork for accelerating real privilege separation.
Nick Roessler, Lucas Atayde, Imani Palmer, Derrick Paul McKee, Jai Pandey, Vasileios P. Kemerlis, Mathias Payer, Adam Bates 0001, Jonathan M. Smith, André DeHon, Nathan Dautenhahn
RAID4
2019 ConfLLVM: A Compiler for Enforcing Data Confidentiality in Low-Level Code
abstract
We present a compiler-based scheme to protect the confidentiality of sensitive data in low-level applications (e.g. those written in C) in the presence of an active adversary. In our scheme, the programmer marks sensitive data by lightweight annotations on the top-level definitions in the source code. The compiler then uses a combination of static dataflow analysis, runtime instrumentation, and a novel taint-aware form of control-flow integrity to prevent data leaks even in the presence of low-level attacks. To reduce runtime overheads, the compiler uses a novel memory layout.
Ajay Brahmakshatriya, Piyus Kedia, Derrick Paul McKee, Deepak Garg 0001, Akash Lal, Aseem Rastogi, Hamed Nemati, Anmol Panda, Pratik Bhatu
EuroSys3
2018 CUP: Comprehensive User-Space Protection for C/C++
abstract
Memory corruption vulnerabilities in C/C++ applications enable attackers to execute code, change data, and leak information. Current memory sanitizers do not provide comprehensive coverage of a program»s data. In particular, existing tools focus primarily on heap allocations with limited support for stack allocations and globals. Orthogonally, existing tools focus on the main executable with limited support for system libraries. Existing tools also suffer from both false positives and false negatives. We present Comprehensive User-Space Protection for C/C++, \sysname, an LLVM sanitizer that provides complete spatial and probabilistic temporal memory safety for C/C++ programs on 64-bit architectures (with a prototype implementation for x86\_64). \sysname uses a hybrid metadata scheme that supports all program data including globals, heap, or stack and maintains Application Binary Interface (ABI) compatibility. Existing approaches have false positives and 8%-25% false negatives on the NIST Juliet test suite. In contrast, \sysname has no false negatives or false positives. \sysname instruments all user-space code, including libc and other system libraries, removing these libraries from the trusted computing base. Supporting all of user space allows \sysname to treat a missed check as a failed check, leading to no false negatives for \sysname. The overhead introduced by \sysname is half that of the state-of-the-art full memory protection on benchmarks where both mechanisms run, and imposes 1.58x overhead when compared to baseline on all benchmarks. Consequently, \sysname is intended as a sanitizer for use by system developers, and to protect truly critical systems.
Nathan Burow, Derrick Paul McKee, Scott A. Carr, Mathias Payer
AsiaCCS2
2018 CFIXX: Object Type Integrity for C++
Nathan Burow, Derrick Paul McKee, Scott A. Carr, Mathias Payer
NDSS2