Hui Xu

CR
h-index13
5papers
58citations
Novelty31%
AI Score39

5 Papers

5.7PLApr 25Code
Annotating and Auditing the Safety Properties of Unsafe Rust

Zihao Rao, Jiping Zhou, Hongliang Tian et al.

In Rust, unsafe code is the sole source of potential undefined behaviors. To avoid misuse, Rust developers should clarify the safety properties for each unsafe API. However, the community currently lacks a key standard for safety documentation: existing safety comments in the source code and safety documentation can be ad hoc and incomplete. This paper presents a tag-centric methodology for auditing the consistency and completeness of safety documentation. We first derive a taxonomy of Safety Tags to formalize natural-language requirements. Second, because API soundness frequently relies on struct invariants, we propose a set of empirical rules to systematically audit the structural consistency of safety documentation. We implemented this methodology in safety-tool, a static linter that automatically enforces structural consistency between local safety annotations and callee requirements. Our approach was applied to the Rust standard library, fixing documentation issues on 27 APIs with 61 safety tags and identifying safety tags that are applicable to 96.1% of the public unsafe APIs in libstd. Furthermore, we have formalized the tagging idea through a Rust RFC to the wider community. We believe that the approach establishes a standardized practice of safety documentation and helps significantly reduce safety perils.

7.1SEDec 5, 2017Code
On Benchmarking the Capability of Symbolic Execution Tools with Logic Bombs

Hui Xu, Zirui Zhao, Yangfan Zhou et al.

Symbolic execution now becomes an indispensable technique for software testing and program analysis. There are several symbolic execution tools available off-the-shelf, and we need a practical benchmark approach to learn their capabilities. Therefore, this paper introduces a novel approach to benchmark symbolic execution tools in a fine-grained and efficient manner. In particular, our approach evaluates the performance of such tools against the known challenges faced by general symbolic execution techniques, such as floating-point numbers and symbolic memories. To this end, we first survey related papers and systematize the challenges of symbolic execution. We extract 12 distinct challenges from the literature and categorize them into two categories: symbolic-reasoning challenges and path-explosion challenges. Then, we develop a dataset of logic bombs and a framework to benchmark symbolic execution tools automatically. For each challenge, our dataset contains several logic bombs, each of which is guarded by a specific challenging problem. If a symbolic execution tool can find test cases to trigger logic bombs, it indicates that the tool can handle the corresponding problems. We have conducted real-world experiments with three popular symbolic execution tools: KLEE, Angr, and Triton. Experimental results show that our approach can reveal their capabilities and limitations in handling particular issues accurately and efficiently. The benchmark process generally takes only dozens of minutes to evaluate a tool. We release our dataset on GitHub as open source, with an aim to better facilitate the community to conduct future work on benchmarking symbolic execution tools.

8.0PLMar 6, 2020Code
Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs

Hui Xu, Zhuangbin Chen, Mingshen Sun et al.

Rust is an emerging programing language that aims at preventing memory-safety bugs without sacrificing much efficiency. The claimed property is very attractive to developers, and many projects start using the language. However, can Rust achieve the memory-safety promise? This paper studies the question by surveying 186 real-world bug reports collected from several origins which contain all existing Rust CVEs (common vulnerability and exposures) of memory-safety issues by 2020-12-31. We manually analyze each bug and extract their culprit patterns. Our analysis result shows that Rust can keep its promise that all memory-safety bugs require unsafe code, and many memory-safety bugs in our dataset are mild soundness issues that only leave a possibility to write memory-safety bugs without unsafe code. Furthermore, we summarize three typical categories of memory-safety bugs, including automatic memory reclaim, unsound function, and unsound generic or trait. While automatic memory claim bugs are related to the side effect of Rust newly-adopted ownership-based resource management scheme, unsound function reveals the essential challenge of Rust development for avoiding unsound code, and unsound generic or trait intensifies the risk of introducing unsoundness. Based on these findings, we propose two promising directions towards improving the security of Rust development, including several best practices of using specific APIs and methods to detect particular bugs involving unsafe code. Our work intends to raise more discussions regarding the memory-safety issues of Rust and facilitate the maturity of the language.

12.3CROct 3, 2017
On Secure and Usable Program Obfuscation: A Survey

Hui Xu, Yangfan Zhou, Yu Kang et al.

Program obfuscation is a widely employed approach for software intellectual property protection. However, general obfuscation methods (e.g., lexical obfuscation, control obfuscation) implemented in mainstream obfuscation tools are heuristic and have little security guarantee. Recently in 2013, Garg et al. have achieved a breakthrough in secure program obfuscation with a graded encoding mechanism and they have shown that it can fulfill a compelling security property, i.e., indistinguishability. Nevertheless, the mechanism incurs too much overhead for practical usage. Besides, it focuses on obfuscating computation models (e.g., circuits) rather than real codes. In this paper, we aim to explore secure and usable obfuscation approaches from the literature. Our main finding is that currently we still have no such approaches made secure and usable. The main reason is we do not have adequate evaluation metrics concerning both security and performance. On one hand, existing code-oriented obfuscation approaches generally evaluate the increased obscurity rather than security guarantee. On the other hand, the performance requirement for model-oriented obfuscation approaches is too weak to develop practical program obfuscation solutions.

5.7CRJun 8, 2015
N-Version Obfuscation: Impeding Software Tampering Replication with Program Diversity

Hui Xu, Yangfan Zhou, Michael R. Lyu

Tamper-resistance is a fundamental software security research area. Many approaches have been proposed to thwart specific procedures of tampering, e.g., obfuscation and self-checksumming. However, to our best knowledge, none of them can achieve theoretically tamper-resistance. Our idea is to impede the replication of tampering via program diversification, and thus increasing the complexity to break the whole software system. To this end, we propose to deliver same featured, but functionally nonequivalent software copies to different machines. We formally define the problem as N-version obfuscation, and provide a viable means to solve the problem. Our evaluation result shows that the time required for breaking a software system is linearly increased with the number of software versions, which is O(n) complexity.