The advantages of large language models (LLMs) in content comprehension and question answering have led to the rapid emergence of LLM agent. Developers across diverse domains are actively building their own agent applications (apps), as these apps can streamline workflows, boost efficiency, or deliver innovative solutions, thereby enhancing the competitiveness of their products. Agent apps are playing an increasingly important role in our daily lives. However, numerous serious vulnerabilities and security issues have been identified in these apps. To effectively manage future security risks, it is essential to systematically understand the unique characteristics of agent app vulnerabilities and their mitigation. In this paper, we present the first comprehensive study on the vulnerabilities of agent apps, the mitigation practices of app developers, and the associated challenges and trade-offs. We identify 14 types of vulnerabilities and 16 root causes across 7 components, based on an analysis of 221 real-world vulnerabilities. Our study further investigates developer reactions, evaluates the effectiveness of various mitigation strategies, and explores the practical challenges and inevitable trade-offs in vulnerability mitigation. Finally, we distill 12 key findings, discuss their implications for agent app developers, maintainers, and security researchers, and offer suggestions for future research directions.

To date, grey-box fuzzing has become an essential technique to detect vulnerabilities implied in Linux-based firmware. However, existing fuzzing approaches commonly encounter three overlooked obstacles stemming from firmware service characteristics, which largely hinder the effectiveness and efficiency of vulnerability identification. Firstly, the multi-process nature of firmware services is oversimplified during both the emulation and the fuzzing procedures, limiting the scope of firmware testing. Furthermore, firmware services usually incorporate customized service protocols, which feature rich and stringent semantic constraints, causing unique challenges for input generation. To address these obstacles, this paper proposes a service-aware grey-box fuzzing tool HouseFuzz. During the firmware emulation, HouseFuzz carefully traverses the system initialization procedure for identifying those network-facing and daemon processes overlooked by existing approaches. After that, during the fuzzing procedure, HouseFuzz features a multi-process fuzzing framework, enabling the comprehensive inspection of firmware services activated via multiple processes. Furthermore, HouseFuzz leverages both offline and online firmware service analysis to capture the token-level semantic constraints of customized service protocols, based on which HouseFuzz can effectively generate high-quality test cases. In evaluation, compared to SoTA grey-box firmware fuzzing approaches, HouseFuzz identified 76% more network services, achieved 24.8% more code coverage, and detected 175% more 0-day vulnerabilities on the same firmware dataset.

Software diffing (a.k.a., code alignment) is a fundamental technique to differentiate similar and dissimilar code pieces between two given software products. It can enable various kinds of critical security analysis, e.g., n-day bug localization, software plagiarism detection, etc. To date, many diffing tools have been proposed dedicated to aligning binaries. However, few research efforts have elaborated on cross-version Android app diffing, largely hindering the security assessment of wild apps. To sum up, existing diffing works usually establish scalability-oriented alignment algorithms, and suffer from significant alignment errors when handling the large codebases of modern apps. To fill this gap, we propose A pk D iffer , a method-level (i.e., function-level) diffing tool dedicated to aligning versions of the same closed-source Android app. A pk D iffer achieves a good balance between scalability and effectiveness, by featuring a two-stage decomposition-based alignment solution. It first decomposes the codebase of each app version, respectively, into multiple functionality units; then tries to precisely align methods that serve equivalent app functionalities across versions. In evaluation, the results show that A pk D iffer noticeably outperforms existing alignment algorithms in precision and recall, while still having a satisfactory time cost. In addition, we used A pk D iffer to track the one-year evolution of 100 popular Google Play apps. By pinpointing the detailed code locations where app versions deviate in privacy collection, we convincingly revealed that app updates may pose ever-evolving privacy threats to end-users.

For the safety assessment of autonomous driving systems (ADS), simulation testing has become an important complementary technique to physical road testing. In essence, simulation testing is a scenario-driven approach, whose effectiveness is highly dependent on the quality of given simulation scenarios. Moreover, simulation scenarios should be encoded into well-formatted files, otherwise, ADS simulation platforms cannot take them as inputs. Without large public datasets of simulation scenario files, both industry and academic applications of ADS simulation testing are hindered.

As highlighted in authoritative standards (e.g., ISO21448), traffic law compliance is a fundamental prerequisite for the commercialization of autonomous driving systems (ADS). Hence, manufacturers are in severe need of techniques to detect harsh driving situations in which the target ADS would violate traffic laws. To achieve this goal, existing works commonly resort to searching-based simulation testing, which continuously adjusts the scenario configurations (e.g., add new vehicles) of initial simulation scenarios and hunts for critical scenarios. Specifically, they apply pre-defined heuristics on each mutated scenario to approximate the likelihood of triggering ADS traffic violations, and accordingly perform searching scheduling. However, with those comparably more critical scenarios in hand, they fail to offer deterministic guidance on which and how scenario configurations should be further mutated to reliably trigger the target ADS misbehaviors. Hence, they inevitably suffer from meaningless efforts to traverse the huge scenario search space. In this work, we propose VioHawk, a novel simulation-based fuzzer that hunts for scenarios that imply ADS traffic violations. Our key idea is that, traffic law regulations can be formally modeled as hazardous/non-hazardous driving areas on the map at each timestamp during ADS simulation testing (e.g., when the traffic light is red, the intersection is marked as hazardous areas). Following this idea, VioHawk works by inducing the autonomous vehicle to drive into the law-specified hazardous areas with deterministic mutation operations. We evaluated the effectiveness of VioHawk in testing industry-grade ADS (i.e., Apollo). We constructed a benchmark dataset that contains 42 ADS violation scenarios against real-world traffic laws. Compared to existing tools, VioHawk can reproduce 3.1X~13.3X more violations within the same time budget, and save 1.6X~8.9X the reproduction time for those identified violations. Finally, with the help of VioHawk, we identified 9+8 previously unknown violations of real-world traffic laws on Apollo 7.0/8.0.

Fuzz driver generation (FDG) is a fundamental technique for fuzzing library software. Existing FDG approaches have been highly successful with open-source libraries. However, in practice, due to the complex nature of OEM Android frameworks (e.g., customized compilation toolchains, extensive codebases, diverse C/C++ language features), it is not straightforward to integrate existing fuzz driver generation tools with OEM Android libraries. To address this challenge, we first systematically summarize the obstacles to applying existing tools (e.g., FuzzGen) to libraries of an OEM Android (i.e., ColorOS), including compatibility, usability, and effectiveness issues. Following this, we developed a new fuzz driver generation tool, namely FuzzGen++, specifically designed to tackle these obstacles one by one. In our evaluation, we demonstrate the advantages of FuzzGen++ in real-world OEM Android frameworks. FuzzGen++ is compatible with OEM Android and can generate fuzz drivers for all its libraries which are not supported by existing works. The additional analysis of the OEM Android code also enhances its usability within the system. Overall, FuzzGen++ has helped automatically generate 21,457 fuzz drivers. Additionally, through fuzz driver ranking and selection solution, FuzzGen++ figured out cut off 95% fuzz drivers which are less useful. FuzzGen++ supports sophisticated C/C++ features in code analysis, ensuring effectiveness. Compared to hand-written fuzz drivers, FuzzGen++ could generate and select fuzz drivers providing a 107.92% coverage improvement. Furthermore, they discovered 6 bugs, showcasing the capability of FuzzGen++ to find real-world issues.

Recent research shows that, even for vulnerability reports archived by MITRE/NIST, they usually contain incomplete information about the software's vulnerable versions, making users of under-reported vulnerable versions at risk. In this work, we address this problem by introducing a fuzzing-based method. Technically, this approach first collects the crashing trace on the reference version of the software. Then, it utilizes the trace to guide the mutation of the PoC input so that the target version could follow the trace similar to the one observed on the reference version. Under the mutated input, we argue that the target version's execution could have a higher chance of triggering the bug and demonstrating the vulnerability's existence. We implement this idea as an automated tool, named VulScope. Using 30 real-world CVEs on 470 versions of software, VulScope is demonstrated to introduce no false positives and only 7.9% false negatives while migrating PoC from one version to another. Besides, we also compare our method with two representative fuzzing tools AFL and AFLGO. We find VulScope outperforms both of these existing techniques while taking the task of PoC migration. Finally, by using VulScope, we identify 330 versions of software that MITRE/NIST fails to report as vulnerable.

Third-party libraries are widely used in Android applications to ease development and enhance functionalities. However, the incorporated libraries also bring new security & privacy issues to the host application, and blur the accounting between application code and library code. Under this situation, a precise and reliable library detector is highly desirable. In fact, library code may be customized by developers during integration and dead library code may be eliminated by code obfuscators during application build process. However, existing research on library detection has not gracefully handled these problems, thus facing severe limitations in practice. In this paper, we propose LibPecker, an obfuscation-resilient, highly precise and reliable library detector for Android applications. LibPecker adopts signature matching to give a similarity score between a given library and an application. By fully utilizing the internal class dependencies inside a library, LibPecker generates a strict signature for each class. To tolerate library code customization and elimination as much as possible, LibPecker introduces adaptive class similarity threshold and weighted class similarity score when calculating library similarity. To quantitatively evaluate the precision and the recall of LibPecker, we perform the first such experiment (to the best of our knowledge) with a large number of libraries and applications. Results show that LibPecker significantly outperforms the state-of-the-art tools in both recall and precision (91% and 98.1% respectively).