Skip to content

USENIX SECURITY

2024

CAMP: Compiler and Allocator-based Heap Memory Protection

Use type-based filter to remove redundant range checks.

2023

CAPSTONE: A Capability-based Foundation for Trustless Secure Memory Access

A unified interface for trustless memory access.

4 properties, then encode the properties in pointers.

FloatZone: Accelerating Memory Error Detection using the Floating Point Unit

Delegate error check control flow to FPU exceptions.

Unanswered Question: enable FPU in some applications may lower the performance.

PUMM: Preventing Use-After-Free Using Execution Unit Partitioning

prior work: one-time allocation; retrofit garbage collection

UNCONTAINED: Uncovering Container Confusion in the Linux Kernel

A framework to detect type confusion bugs originating from incorrect downcasting operations in non-object-oriented languages, here is the project page.

Method: dynamic analysis using sanitizers.

MTSan: A Feasible and Practical Memory Sanitizer for Fuzzing COTS Binaries

Q1: specific challenging for x86 cpu fuzzing Q2: how to make sure the golden model is correct

Viper: Spotting Syscall-Guard Variables for Data-Only Attacks

BranchForce to flip branch to determine if a variable is security related.

AEX-Notify: Thwarting Precise Single-Stepping Attacks through Interrupt Awareness for Intel SGX Enclaves

Jinn: Hijacking Safe Programs with Trojans

ICSPatch: Automated Vulnerability Localization and Non-Intrusive Hotpatching in Industrial Control Systems using Data Dependence Graphs

ARMore: Pushing Love Back Into Binaries

KextFuzz: Fuzzing macOS Kernel EXTensions on Apple Silicon via Exploiting Mitigations

TRust: A Compilation Framework for In-process Isolation to Protect Safe Rust against Untrusted Code

SHELTER: Extending Arm CCA with Isolation in User Space

Guarding Serverless Applications with Kalium

Security challenges:

  1. Vulnerabilities in 3rd-party libraries can be exploited to control flow and data flow of serverless applications.
  2. Existing scanning tools and log-based anomaly detection are only useful for detecting known vulnerabilities and non real-time attack detection.
  3. Information flow control (IFC) based techniques are to solve serverless data confidentiality. However, serverless data integrity is not solved.

Design patterns to improve serverless security:

  1. Tenants need to externalize the data produced by the function to other services for later use, to avoid data loss due to the stateless nature of serverless functions.
  2. Model each dedicated function individually and construct a global view of the application.
  3. Decomposition of an application to enforce customized policies.

TODO

NVLeak: Off-Chip Side-Channel Attacks via Non-Volatile Memory Systems

Defenses against microarchitectural attacks:

  • internal to the CPU core
  • isolate these resources for security-critical operations spatially and temporally
  • flushing CPU resources across context switching or making sure untrusted threads are not simultaneously executed on the same core
  • shared CPU cache and its directory structure
  • partitioning the cache and randomizing cache accesses
  • yet with performance penalty

Contribution:

  1. reverse-engineering
  2. constructing convert channels
  3. side-channel attack case studies
  4. mitigations

reverse-engineering details:

  1. Pointer chasing microbenchmark
  2. Recovering cache capacity
  3. Recovering L1/L2 NVCache block size
  4. Recovering CPU WPQ structure
  5. Recovering NVCache associativity and number of sets

mitigations (future works):

  1. avoid allocating memory in a single set in the L2 NVCache (implemented)
  2. distinguish memory requests from different security domains at the NVRAM DIMM level

2022

A Harware-Software Co-design for Efficient Intra-Enclave Isolation

Drifuzz: Harvesting Bugs in Device Drivers from Golden Seeds

Tightly Seal Your Sensitive Pointers with PACTIGHT

Fuzzing Hardware Like Software

2021

Swivel: Hardening WebAssembly against Spectre

sandbox breakout attacks and sandbox poisoning attacks are the main issues. sandbox breakout attacks can be mitigated by partition distrusting code into separate processes. Yet it cannot sovle sandbox poisoning attacks and hurts Wasm's scalability and performance.

Techniques:

  1. Tolerant of possible RSB (return stack buffer) underflow.
  2. Poisoned BTB (branch target buffer) or CBP (conditional branch predictor)

Solutions:

Swivel first compiele Wasm code into linear blocks. All transfers of control are at the block boundry (kinds of like basic blocks). All memory accesses within a linear block are masked to the sandbox memory.

  • SFI
  • (Raise the bar) use ASLR to randomize the placement of each Wasm sandbox and flushes the BTB on each sandbox boundary crossing.
  • (Deterministic) Rewrites conditional branches to indirect jumps — thereby completely bypassing the CBP (which cannot be directly flushed) and relying solely on the BTB (which can).
  • Hardware-assisted hardening:
  • Add endbranch to demarcate valid jump targets.
  • (Raise the bar) uses ASLR to randomize the location of each sandbox and flushes the BTB on sandbox entry. (Not sandbox exit with endbranch)
  • (Deterministic) register interlocking which tracks the control flow of the Wasm sandbox and turns every misspeculated memory access into an access to an empty guard page. At the beginning of each linear block, check the value of the interlock register corresponds to the static block label using cmov instructions.
    • Create data dependencies and thus prevent speculation.

A linear block is safe with:

  1. Masking memory accesses, mask-after-unspill.
  2. Pinning heap register to store the address of the sandbox heap.
  3. Bounds checking on each access to indirect call tables and switch tables, with Speculative load hardening.
  4. Protecting returns with shadow stack.

Limitations:

  1. Do not ensure that interlock labels are unique to each linear block, but rather reuse interlock labels.
  2. Host shall not save secrets. Yet secrets can be placed at another sandbox.
  3. Hyperthreading does not work on Swivel-SFI. Yet Intel provide single-threaded indirect branch predictors (STIBP).

What does "mask" mean?

2020

Agamotto: Accelerating Kernel Driver Fuzzing with Lightweight Virtual Machine Checkpoints

TODO

Retrofitting Fine Grain Isolation in the Firefox Renderer [Code]

RLBox: wasm-based sandbox, making data-flow and control-flow explicit with types.

Data-flow bugs:

  1. Failing to sanitize data
  2. Missing pointer swizzles
  3. Leaking pointers
  4. Double fetch

Control-flow bugs:

  1. Corrupted callback state
  2. Unexpected callback invocation
  3. Callback state exchange attacks

RLBox design

For data flow safety:

  1. All data flows from the sandbox into the renderer are taintied. For example, sandbox_invoke() taints its return value, and sandbox_callback() taints parameters.
  2. RLBox automatically swizzles and unswizzles pointers appropriately when pointers cross the renderer-library boundary.
  3. RLBox automatically applies pointer-bounds sanitization checks when tainted pointers are created.

For data validation:

RLBox guarantees that sandbox code cannot concurrently alter the tainted data. By providing a freeze() method, RLBox makes a copy of the value into renderer memory and ensures that the original value (in sandbox memory) has not changed. RLBox disallows the renderer from reading freezable variables until they are frozen. RLBox allows the renderer to write to frozon variables.

For control flow safety:

  1. Whitelisting callbacks and preventing renderer pointers leak into the sandbox.
  2. setjmp() and longjmp() can only be called by trampoline from sandboxes.

Question: 1. What is base type (RLBOX_DEFINE_BASE_TYPES_FOR(mylib, noop);)

Everything Old is New Again: Binary Security of WebAssembly

2019

uXOM: Efficient eXecute-Only Memory on ARM Cortex-M

TODO

ERIM: Secure, Efficient In-process Isolation with Protection Keys (MPK)

  • Prevent MPK exploitation
  • Safe call gates
  • Prevent execution of permission register updates outside of call gates
  • Creating usable binaries
  • Inadvertent PKRU update instruction
  • Rewrite strategy
  • Evaluation
  • Frequently-switching use cases
  • 10% higher throughput compared to best existing technique

Call Gates

  WRPKRU (RW_TRUSTED)

  // entry point to trusted

  WRPKRU (DIS_TRUSTED)
  cmp DIS_TRUSTED, EAX
  je continue
  exit
continue:

2017

kAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels

  • Intel Processor Trace (PT) technology
  • physical CPU, logical CPU, virtual CPU and Intel VT-x

Inferring Fine-grained Control Flow Inside SGX Enclaves with Branch Shadowing

TODO