High System-Code Security with Low Overhead

Security vulnerabilities plague modern systems because writing secure systems code is hard. Promising approaches can retrofit security automatically via runtime checks that implement the desired security policy; these checks guard critical operations, like memory accesses. Alas, the induced slowdown usually exceeds by a wide margin what system users are willing to tolerate in production, so these tools are hardly ever used. As a result, the insecurity of real-world systems persists. We present an approach in which developers/operators can specify what level of overhead they find acceptable for a given workload (e.g., 5%); our proposed tool ASAP then automatically instruments the program to maximize its security while staying within the specified "overhead budget." Two insights make this approach effective: most overhead in existing tools is due to only a few "hot" checks, whereas the checks most useful to security are typically "cold" and cheap. We evaluate ASAP on programs from the Phoronix and SPEC benchmark suites. It can precisely select the best points in the security-performance spectrum. Moreover, we analyzed existing bugs and security vulnerabilities in RIPE, OpenSSL, and the Python interpreter, and found that the protection level offered by the ASAP approach is sufficient to protect against all of them

Improving systems software security through program analysis and instrumentation

Security and reliability bugs are prevalent in systems software. Systems code is often written in low-level languages like C/C++, which offer many benefits but also delegate memory management and type safety to programmers. This invites bugs that cause crashes or can be exploited by attackers to take control of the program. This thesis presents techniques to detect and fix security and reliability issues in systems software without burdening the software developers. First, we present code-pointer integrity (CPI), a technique that combines static analysis with compile-time instrumentation to guarantee the integrity of all code pointers in a program and thereby prevent all control-flow hijack attacks. We also present code-pointer separation (CPS), a relaxation of CPI with better performance properties. CPI and CPS offer substantially better security-to-overhead ratios than the state of the art in control flow hijack defense mechanisms, they are practical (we protect a complete FreeBSD system and over 100 packages like apache and postgresql), effective (prevent all attacks in the RIPE benchmark), and efficient: on SPEC CPU2006, CPS averages 1.2% overhead for C and 1.9% for C/C++, while CPIâs overhead is 2.9% for C and 8.4% for C/C++. Second, we present DDT, a tool for testing closed-source device drivers to automatically find bugs like memory errors or race conditions. DDT showcases a combination of a form of program analysis called selective symbolic execution with virtualization to thoroughly exercise tested drivers and produce detailed, executable traces for every path that leads to a failure. We applied DDT to several closed-source Microsoft-certified Windows device drivers and discovered 14 serious new bugs that can cause crashes or compromise security of the entire system. Third, we present a technique for increasing the scalability of symbolic execution by merging states obtained on different execution paths. State merging reduces the number of states to analyze, but the merged states can be more complex and harder to analyze than their individual components. We introduce query count estimation, a technique to reason about the analysis time of merged states and decide which states to merge in order to achieve optimal net performance of symbolic execution. We also introduce dynamic state merging, a technique for merging states that interacts favorably with search strategies employed by practical bug finding tools, such as DDT and KLEE. Experiments on the 96 GNU Coreutils show that our approach consistently achieves several orders of magnitude speedup over previously published results

Hydrogen Tank Rupture in Fire in the Open Atmosphere: Hazard Distance Defined by Fireball

The engineering correlations for assessment of hazard distance defined by a size of fireball after either liquid hydrogen spill combustion or high-pressure hydrogen tank rupture in a fire in the open atmosphere (both for stand-alone and under-vehicle tanks) are presented. The term “fireball size” is used for the maximum horizontal size of a fireball that is different from the term “fireball diameter” applied to spherical or semi-spherical shape fireballs. There are different reasons for a fireball to deviate from a spherical shape, e.g., in case of tank rupture under a vehicle, the non-instantaneous opening of tank walls, etc. Two conservative correlations are built using theoretical analysis, numerical simulations, and experimental data available in the literature. The theoretical model for hydrogen fireball size assumes complete isobaric combustion of hydrogen in air and presumes its hemispherical shape as observed in the experiments and the simulations for tank rupturing at the ground level. The dependence of the fireball size on hydrogen mass and fireball’s diameter-to-height ratio is discussed. The correlation for liquid hydrogen release fireball is based on the experiments by Zabetakis (1964). The correlations can be applied as engineering tools to access hazard distances for scenarios of liquid or gaseous hydrogen storage tank rupture in a fire in the open atmosphere

Structural characteristics of zinc oxide thin films obtained by chemial bath deposition

Due to the large band gap, high charge-carrier mobility, high exciton binding energy, low toxicity, high thermal and radiation stability, zinc oxide is considered as a promising material for fabrication gas detectors, sensors of ultraviolet light, electroluminescence devices. Furthermore, chemically deposited ZnO films are widely used as conductive and optical cover layers of solar cells. Among the various methods of ZnO thin films obtaining, chemical bath deposition is one of the promising non-vacuum method of synthesis of layers with controllable structural and electrophysical properties

ProbeGuard:Mitigating Probing Attacks Through Reactive Program Transformations

Many modern defenses against code reuse rely on hiding sensitive data such as shadow stacks in a huge memory address space. While much more efficient than traditional integritybased defenses, these solutions are vulnerable to probing attacks which quickly locate the hidden data and compromise security. This has led researchers to question the value of information hiding in real-world software security. Instead, we argue that such a limitation is not fundamental and that information hiding and integrity-based defenses are two extremes of a continuous spectrum of solutions. We propose a solution, ProbeGuard, that automatically balances performance and security by deploying an existing information hiding based baseline defense and then incrementally moving to more powerful integrity-based defenses by hotpatching when probing attacks occur. ProbeGuard is efficient, provides strong security, and gracefully trades off performance upon encountering more probing primitives

Testing Closed-Source Binary Device Drivers with DDT

DDT is a system for testing closed-source binary device drivers against undesired behaviors, like race conditions, memory errors, resource leaks, etc. One can metaphorically think of it as a pesticide against device driver bugs. DDT combines virtualization with a specialized form of symbolic execution to thoroughly exercise tested drivers; a set of modular dynamic checkers identify bug conditions and produce detailed, executable traces for every path that leads to a failure. These traces can be used to easily reproduce and understand the bugs, thus both proving their existence and helping debug them. We applied DDT to several closed-source Microsoft-certified Windows device drivers and discovered 14 serious new bugs. DDT is easy to use, as it requires no access to source code and no assistance from users. We therefore envision DDT being useful not only to developers and testers, but also to consumers who want to avoid running buggy drivers in their OS kernels