Searcharxiv⌕ Search

arXiv subjects

Zhiqiang Lin

Publications and source records attributed to Zhiqiang Lin.

52 records · Page 3Linked to original sources

Cocoon: Static Information Flow Control in Rust

Information flow control (IFC) provides confidentiality by enforcing noninterference, which ensures that high-secrecy values cannot affect low-secrecy values. Prior work introduces fine-grained IFC approaches that modify the programming language and use nonstandard compilation tools, impose run-time overhead, or report false secrecy leaks -- all of which hinder adoption. This paper presents Cocoon, a Rust library for static type-based IFC that uses the unmodified Rust language and compiler. The key insight of Cocoon lies in leveraging Rust's type system and procedural macros to establish an effect system that enforces noninterference. A performance evaluation shows that using Cocoon increases compile time but has no impact on application performance. To demonstrate Cocoon's utility, we retrofitted two popular Rust programs, the Spotify TUI client and Mozilla's Servo browser engine, to use Cocoon to enforce limited confidentiality policies.

cs.PL↗

SoK: Security of Cross-chain Bridges: Attack Surfaces, Defenses, and Open Problems

Cross-chain bridges are used to facilitate token and data exchanges across blockchains. Although bridges are becoming increasingly popular, they are still in their infancy and have been attacked multiple times recently, causing significant financial loss. Although there are numerous reports online explaining each of the incidents on cross-chain bridges, they are scattered over the Internet, and there is no work that analyzes the security landscape of cross-chain bridges in a holistic manner. To fill the gap, in this paper, we performed a systematic study of cross-chain bridge security issues. First, we summarize the characteristics of existing cross-chain bridges, including their usages, verification mechanisms, communication models, and three categorizations. Based on these characteristics, we identify 12 potential attack vectors that attackers may exploit. Next, we introduce a taxonomy that categorizes cross-chain attacks in the past two years into 10 distinct types, and then provide explanations for each vulnerability type, accompanied by Solidity code examples. We also discuss existing and potential defenses, as well as open questions and future research directions on cross-chain bridges. We believe that this systematization can shed light on designing and implementing cross-chain bridges with higher security and, more importantly, facilitating future research on building a better cross-chain bridge ecosystem.

cs.CR↗

Binary Code Summarization: Benchmarking ChatGPT/GPT-4 and Other Large Language Models

Binary code summarization, while invaluable for understanding code semantics, is challenging due to its labor-intensive nature. This study delves into the potential of large language models (LLMs) for binary code comprehension. To this end, we present BinSum, a comprehensive benchmark and dataset of over 557K binary functions and introduce a novel method for prompt synthesis and optimization. To more accurately gauge LLM performance, we also propose a new semantic similarity metric that surpasses traditional exact-match approaches. Our extensive evaluation of prominent LLMs, including ChatGPT, GPT-4, Llama 2, and Code Llama, reveals 10 pivotal insights. This evaluation generates 4 billion inference tokens, incurred a total expense of 11,418 US dollars and 873 NVIDIA A100 GPU hours. Our findings highlight both the transformative potential of LLMs in this field and the challenges yet to be overcome.

cs.CR↗

SoK: Decoding the Super App Enigma: The Security Mechanisms, Threats, and Trade-offs in OS-alike Apps

The super app paradigm, exemplified by platforms such as WeChat and AliPay, has revolutionized the mobile app landscape by enabling third-party developers to deploy add-ons within these apps. These add-ons, known as miniapps, leverage user data hosted by the super app platforms to provide a wide range of services, such as shopping and gaming. With the rise of miniapps, super apps have transformed into "operating systems", offering encapsulated APIs to miniapp developers as well as in-app miniapp stores for users to explore and download miniapps. In this paper, we provide the first systematic study to consolidate the current state of knowledge in this field from the security perspective: the security measures, threats, and trade-offs of this paradigm. Specifically, we summarize 13 security mechanisms and 10 security threats in super app platforms, followed by a root cause analysis revealing that the security assumptions still may be violated due to issues in underlying systems, implementation of isolation, and vetting. Additionally, we also systematize open problems and trade-offs that need to be addressed by future works to help enhance the security and privacy of this new paradigm.

cs.CR↗

Uncovering and Exploiting Hidden APIs in Mobile Super Apps

Mobile applications, particularly those from social media platforms such as WeChat and TikTok, are evolving into "super apps" that offer a wide range of services such as instant messaging and media sharing, e-commerce, e-learning, and e-government. These super apps often provide APIs for developers to create "miniapps" that run within the super app. These APIs should have been thoroughly scrutinized for security. Unfortunately, we find that many of them are undocumented and unsecured, potentially allowing miniapps to bypass restrictions and gain higher privileged access. To systematically identify these hidden APIs before they are exploited by attackers, we developed a tool APIScope with both static analysis and dynamic analysis, where static analysis is used to recognize hidden undocumented APIs, and dynamic analysis is used to confirm whether the identified APIs can be invoked by an unprivileged 3rdparty miniapps. We have applied APIScope to five popular super apps (i.e., WeChat, WeCom, Baidu, QQ, and Tiktok) and found that all of them contain hidden APIs, many of which can be exploited due to missing security checks. We have also quantified the hidden APIs that may have security implications by verifying if they have access to resources protected by Android permissions. Furthermore, we demonstrate the potential security hazards by presenting various attack scenarios, including unauthorized access to any web pages, downloading and installing malicious software, and stealing sensitive information. We have reported our findings to the relevant vendors, some of whom have patched the vulnerabilities and rewarded us with bug bounties.

cs.CR↗

Don't Leak Your Keys: Understanding, Measuring, and Exploiting the AppSecret Leaks in Mini-Programs

Mobile mini-programs in WeChat have gained significant popularity since their debut in 2017, reaching a scale similar to that of Android apps in the Play Store. Like Google, Tencent, the provider of WeChat, offers APIs to support the development of mini-programs and also maintains a mini-program market within the WeChat app. However, mini-program APIs often manage sensitive user data within the social network platform, both on the WeChat client app and in the cloud. As a result, cryptographic protocols have been implemented to secure data access. In this paper, we demonstrate that WeChat should have required the use of the "appsecret" master key, which is used to authenticate a mini-program, to be used only in the mini-program back-end. If this key is leaked in the front-end of the mini-programs, it can lead to catastrophic attacks on both mini-program developers and users. Using a mini-program crawler and a master key leakage inspector, we measured 3,450,586 crawled mini-programs and found that 40,880 of them had leaked their master keys, allowing attackers to carry out various attacks such as account hijacking, promotion abuse, and service theft. Similar issues were confirmed through testing and measuring of Baidu mini-programs too. We have reported these vulnerabilities and the list of vulnerable mini-programs to Tencent and Baidu, which awarded us with bug bounties, and also Tencent recently released a new API to defend against these attacks based on our findings.

cs.CR↗

An Empirical Study on Ethereum Private Transactions and the Security Implications

Recently, Decentralized Finance (DeFi) platforms on Ethereum are booming, and numerous traders are trying to capitalize on the opportunity for maximizing their benefits by launching front-running attacks and extracting Miner Extractable Values (MEVs) based on information in the public mempool. To protect end users from being harmed and hide transactions from the mempool, private transactions, a special type of transactions that are sent directly to miners, were invented. Private transactions have a high probability of being packed to the front positions of a block and being added to the blockchain by the target miner, without going through the public mempool, thus reducing the risk of being attacked by malicious entities. Despite the good intention of inventing private transactions, due to their stealthy nature, private transactions have also been used by attackers to launch attacks, which has a negative impact on the Ethereum ecosystem. However, existing works only touch upon private transactions as by-products when studying MEV, while a systematic study on private transactions is still missing. To fill this gap and paint a complete picture of private transactions, we take the first step towards investigating the private transactions on Ethereum. In particular, we collect large-scale private transaction datasets and perform analysis on their characteristics, transaction costs and miner profits, as well as security impacts. This work provides deep insights on different aspects of private transactions.

cs.CR↗

CROSSLINE: Breaking "Security-by-Crash" based Memory Isolation in AMD SEV

AMD's Secure Encrypted Virtualization (SEV) is an emerging security feature on AMD processors that allows virtual machines to run on encrypted memory and perform confidential computing even with an untrusted hypervisor. This paper first demystifies SEV's improper use of address space identifier (ASID) for controlling accesses of a VM to encrypted memory pages, cache lines, and TLB entries. We then present the CROSSLINE attacks, a novel class of attacks against SEV that allow the adversary to launch an attacker VM and change its ASID to that of the victim VM to impersonate the victim. We present two variants of CROSSLINE attacks: CROSSLINE V1 decrypts victim's page tables or memory blocks following the format of a page table entry; CROSSLINE V2 constructs encryption and decryption oracles by executing instructions of the victim VM. We have successfully performed CROSSLINE attacks on SEV and SEV-ES processors.

cs.CR↗

WLAN-Log-Based Superspreader Detection in the COVID-19 Pandemic

Identifying "superspreaders" of disease is a pressing concern for society during pandemics such as COVID-19. Superspreaders represent a group of people who have much more social contacts than others. The widespread deployment of WLAN infrastructure enables non-invasive contact tracing via people's ubiquitous mobile devices. This technology offers promise for detecting superspreaders. In this paper, we propose a general framework for WLAN-log-based superspreader detection. In our framework, we first use WLAN logs to construct contact graphs by jointly considering human symmetric and asymmetric interactions. Next, we adopt three vertex centrality measurements over the contact graphs to generate three groups of superspreader candidates. Finally, we leverage SEIR simulation to determine groups of superspreaders among these candidates, who are the most critical individuals for the spread of disease based on the simulation results. We have implemented our framework and evaluate it over a WLAN dataset with 41 million log entries from a large-scale university. Our evaluation shows superspreaders exist on university campuses. They change over the first few weeks of a semester, but stabilize throughout the rest of the term. The data also demonstrate that both symmetric and asymmetric contact tracing can discover superspreaders, but the latter performs better with daily contact graphs. Further, the evaluation shows no consistent differences among three vertex centrality measures for long-term (i.e., weekly) contact graphs, which necessitates the inclusion of SEIR simulation in our framework. We believe our proposed framework and these results may provide timely guidance for public health administrators regarding effective testing, intervention, and vaccination policies.

cs.SI↗

ACOUSTIC-TURF: Acoustic-based Privacy-Preserving COVID-19 Contact Tracing

In this paper, we propose a new privacy-preserving, automated contact tracing system, ACOUSTIC-TURF, to fight COVID-19 using acoustic signals sent from ubiquitous mobile devices. At a high level, ACOUSTIC-TURF adaptively broadcasts inaudible ultrasonic signals with randomly generated IDs in the vicinity. Simultaneously, the system receives other ultrasonic signals sent from nearby (e.g., 6 feet) users. In such a system, individual user IDs are not disclosed to others and the system can accurately detect encounters in physical proximity with 6-foot granularity. We have implemented a prototype of ACOUSTIC-TURF on Android and evaluated its performance in terms of acoustic-signal-based encounter detection accuracy and power consumption at different ranges and under various occlusion scenarios. Experimental results show that ACOUSTIC-TURF can detect multiple contacts within a 6-foot range for mobile phones placed in pockets and outside pockets. Furthermore, our acoustic-signal-based system achieves greater precision than wireless-signal-based approaches when contact tracing is performed through walls. ACOUSTIC-TURF correctly determines that people on opposite sides of a wall are not in contact with one another, whereas the Bluetooth-based approaches detect nonexistent contacts among them.

cs.CR↗

Analyzing Control Flow Integrity with LLVM-CFI

Control-flow hijacking attacks are used to perform malicious com-putations. Current solutions for assessing the attack surface afteracontrol flow integrity(CFI) policy was applied can measure onlyindirect transfer averages in the best case without providing anyinsights w.r.t. the absolute calltarget reduction per callsite, and gad-get availability. Further, tool comparison is underdeveloped or notpossible at all. CFI has proven to be one of the most promising pro-tections against control flow hijacking attacks, thus many effortshave been made to improve CFI in various ways. However, there isa lack of systematic assessment of existing CFI protections. In this paper, we presentLLVM-CFI, a static source code analy-sis framework for analyzing state-of-the-art static CFI protectionsbased on the Clang/LLVM compiler framework.LLVM-CFIworksby precisely modeling a CFI policy and then evaluating it within aunified approach.LLVM-CFIhelps determine the level of securityoffered by different CFI protections, after the CFI protections weredeployed, thus providing an important step towards exploit cre-ation/prevention and stronger defenses. We have usedLLVM-CFIto assess eight state-of-the-art static CFI defenses on real-worldprograms such as Google Chrome and Apache Httpd.LLVM-CFIprovides a precise analysis of the residual attack surfaces, andaccordingly ranks CFI policies against each other.LLVM-CFIalsosuccessfully paves the way towards construction of COOP-like codereuse attacks and elimination of the remaining attack surface bydisclosing protected calltargets under eight restrictive CFI policies.

cs.CR↗

On the (In)security of Bluetooth Low Energy One-Way Secure Connections Only Mode

To defeat security threats such as man-in-the-middle (MITM) attacks, Bluetooth Low Energy (BLE) 4.2 and 5.x introduce the Secure Connections Only mode, under which a BLE device accepts only secure paring protocols including Passkey Entry and Numeric Comparison from an initiator, e.g., an Android mobile. However, the BLE specification does not explicitly require the Secure Connection Only mode of the initiator. Taking the Android's BLE programming framework for example, we found that it cannot enforce secure pairing, invalidating the security protection provided by the Secure Connection Only mode. The same problem applies to Apple iOS too. Specifically, we examine the life cycle of a BLE pairing process in Android and identify four severe design flaws. These design flaws can be exploited by attackers to perform downgrading attacks, forcing the BLE pairing protocols to run in the insecure mode without the users' awareness. To validate our findings, we selected and tested 18 popular BLE commercial products and our experimental results proved that downgrading attacks and MITM attacks were all possible to these products. All 3501 BLE apps from Androzoo are also subject to these attacks. For defense, we have designed and implemented a prototype of the Secure Connection Only mode on Android 8 through the Android Open Source Project (AOSP). We have reported the identified BLE pairing vulnerabilities to Bluetooth Special Interest Group (SIG), Google, Apple, Texas Instruments (TI) and all of them are actively addressing this issue. Google rated the reported security flaw a High Severity.

cs.CR↗

Injected and Delivered: Fabricating Implicit Control over Actuation Systems by Spoofing Inertial Sensors

Inertial sensors provide crucial feedback for control systems to determine motional status and make timely, automated decisions. Prior efforts tried to control the output of inertial sensors with acoustic signals. However, their approaches did not consider sample rate drifts in analog-to-digital converters as well as many other realistic factors. As a result, few attacks demonstrated effective control over inertial sensors embedded in real systems. This work studies the out-of-band signal injection methods to deliver adversarial control to embedded MEMS inertial sensors and evaluates consequent vulnerabilities exposed in control systems relying on them. Acoustic signals injected into inertial sensors are out-of-band analog signals. Consequently, slight sample rate drifts could be amplified and cause deviations in the frequency of digital signals. Such deviations result in fluctuating sensor output; nevertheless, we characterize two methods to control the output: digital amplitude adjusting and phase pacing. Based on our analysis, we devise non-invasive attacks to manipulate the sensor output as well as the derived inertial information to deceive control systems. We test 25 devices equipped with MEMS inertial sensors and find that 17 of them could be implicitly controlled by our attacks. Furthermore, we investigate the generalizability of our methods and show the possibility to manipulate the digital output through signals with relatively low frequencies in the sensing channel.

cs.CR↗

SgxPectre Attacks: Stealing Intel Secrets from SGX Enclaves via Speculative Execution

This paper presents SgxPectre Attacks that exploit the recently disclosed CPU bugs to subvert the confidentiality and integrity of SGX enclaves. Particularly, we show that when branch prediction of the enclave code can be influenced by programs outside the enclave, the control flow of the enclave program can be temporarily altered to execute instructions that lead to observable cache-state changes. An adversary observing such changes can learn secrets inside the enclave memory or its internal registers, thus completely defeating the confidentiality guarantee offered by SGX. To demonstrate the practicality of our SgxPectre Attacks, we have systematically explored the possible attack vectors of branch target injection, approaches to win the race condition during enclave's speculative execution, and techniques to automatically search for code patterns required for launching the attacks. Our study suggests that any enclave program could be vulnerable to SgxPectre Attacks since the desired code patterns are available in most SGX runtimes (e.g., Intel SGX SDK, Rust-SGX, and Graphene-SGX). Most importantly, we have applied SgxPectre Attacks to steal seal keys and attestation keys from Intel signed quoting enclaves. The seal key can be used to decrypt sealed storage outside the enclaves and forge valid sealed data; the attestation key can be used to forge attestation signatures. For these reasons, SgxPectre Attacks practically defeat SGX's security protection. This paper also systematically evaluates Intel's existing countermeasures against SgxPectre Attacks and discusses the security implications.

cs.CR↗

FreeGuard: A Faster Secure Heap Allocator

In spite of years of improvements to software security, heap-related attacks still remain a severe threat. One reason is that many existing memory allocators fall short in a variety of aspects. For instance, performance-oriented allocators are designed with very limited countermeasures against attacks, but secure allocators generally suffer from significant performance overhead, e.g., running up to 10x slower. This paper, therefore, introduces FreeGuard, a secure memory allocator that prevents or reduces a wide range of heap-related attacks, such as heap overflows, heap over-reads, use-after-frees, as well as double and invalid frees. FreeGuard has similar performance to the default Linux allocator, with less than 2% overhead on average, but provides significant improvement to security guarantees. FreeGuard also addresses multiple implementation issues of existing secure allocators, such as the issue of scalability. Experimental results demonstrate that FreeGuard is very effective in defending against a variety of heap-related attacks.

cs.OS↗

Energy Attacks on Mobile Devices

All mobile devices are energy-constrained. They use batteries that allows using the device for a limited amount of time. In general, energy attacks on mobile devices are denial of service (DoS) type of attacks. While previous studies have analyzed the energy attacks in servers, no existing work has analyzed the energy attacks on mobile devices. As such, in this paper, we present the first systematic study on how to exploit the energy attacks on smartphones. In particular, we explore energy attacks from the following aspect: hardware components, software resources, and network communications through the design and implementation of concrete malicious apps, and malicious web pages. We quantitatively show how quickly we can drain the battery through each individual attack, as well as their combinations. Finally, we believe energy exploit will be a practical attack vector and mobile users should be aware of this type of attacks.

cs.CR↗