Data binding has been widely adopted by popular web frameworks due to its convenience of automatically binding web request parameters to the web program's properties. However, its improper implementation in web frameworks exposes sensitive properties, leading to data binding vulnerabilities, which can be exploited to launch severe attacks, such as the Spring4Shell remote code execution. Despite their criticalness, these issues are overlooked, and there is no systematic study addressing them. This paper presents the first automatic analysis of the data binding vulnerabilities in Java web frameworks. We develop an automatic Data bInding Vulnerabilities dEtectoR, named DIVER, to analyze data binding vulnerabilities. DIVER employs three new techniques: the Nested Property Graph-based Extraction to extract nested properties, the Bind-Site Instrumentation-based Identification to identify bindable nested properties, and the Property-aware Fuzzing to trigger and detect data binding vulnerabilities. We evaluated DIVER on two widely used Java web frameworks, Spring and Grails, and discovered 81 data binding vulnerabilities. These vulnerabilities can be exploited to launch remote code execution, arbitrary file read, and denial of service attacks. We have responsibly reported these vulnerabilities to the corresponding teams and helped to fix them. Three new CVEs with critical and high severity ratings have been assigned to us, including the infamous Spring4Shell.

Conflict-based cache attacks can leak critical information from target programs. Accordingly, randomization-based cache designs have emerged as an efficient and LLC-favorable way to mitigate such attacks. However, later investigations have revealed several problems with these designs. Specifically, we identify limited randomness and coarse-grained protection as key issues of previous designs. To solve these issues, we proposeRecast, a secure cache design with address-sensitive secret generation and tweakable index randomization. Our insight is that cache modules at different levels can work collaboratively to enhance their security. Address-sensitive secret generation in private caches generates a secret value for each address upon cache misses. The shared cache in Recast uses tweakable index randomization, where the cryptographic function uses the secret value from private caches as the input to calculate the cache set index. Therefore, Recast achieves fine-grained dynamic mapping. We implement Recast in the gem5 simulator. We use a micro-benchmark and a benchmark suite to showcase the security of Recast. Our performance evaluations on SPEC 2017 and PARSEC benchmarks show that Recast incurs 2.29% and 2.03% performance overhead. Moreover, Recast with the LRU replacement policy has only 0.51% and 1.04% performance overhead on the two benchmarks. Therefore, Recast provides higher security guarantees with minimal performance overhead.

Oblivious RAM (ORAM) remains a bittersweet protection of memory access patterns because of its prohibitively high overhead. The root cause is that ORAM hides intended accesses among a sufficiently large number of dummy accesses. Most existing optimizations mitigate memory accesses using architectural enhancements (e.g., cache) yet few of them improve the efficiency of ORAM primitives per se. In this paper, we identify path-grained static scheduling as a fundamental ORAM performance bottleneck. We propose level-grained dynamic scheduling that directly optimizes ORAM primitives to boost efficiency. It enables ORAM to service more than one request per path and write paths batch wise. We can thus boost ORAM efficiency through handling queued requests as soon as possible and remove as many redundant accesses as possible. Since optimized memory accesses still target the same set of paths, dynamic scheduling preserves ORAM security. We implement dynamic scheduling through Hitchhiker ORAM. In comparison with the state-of-the-art primitive-optimized Fork Path ORAM, Hitchhiker ORAM yields 31.5% fewer memory accesses, 60.2% shorter latency, and 40.7% less energy consumption, being 2.5× faster. In comparison with the state-of-the-art architecture-optimized$\rho$, Hitchhiker ORAM is 1.5× faster and the integrated version—$\rho$-Hitchhiker ORAM is 2.0× faster.