Auflistung nach Autor:in "Zeller, Andreas"
1 - 10 von 21
Treffer pro Seite
Sortieroptionen
- KonferenzbeitragAppMining(Software Engineering 2017, 2017) Avdiienko, Vitalii; Kuznetsov, Konstantin; Gorla, Alessandra; Zeller, Andreas; Arzt, Steven; Rasthofer, Siegfried; Bodden, EricA fundamental question of security analysis is: When is a behavior normal, and when is it not? We present techniques that extract behavior patterns from thousands of apps—patters that represent normal behavior, such as “A travel app normally does not access stored text messages”. Combining data flow analysis with app descriptions and GUI data from both apps and their stores allows for massive machine learning, which then also allows to detect yet unknown malware by classifying it as abnormal.
- KonferenzbeitragDetecting Information Flow by Mutating Input Data(Software Engineering und Software Management 2018, 2018) Mathis, Björn; Avdiienko, Vitalii; Soremekun, Ezekiel O.; Böhme, Marcel; Zeller, Andreas[Accepted as full paper for ASE 2017] Analyzing information flow is central in assessing the security of applications. However, static and dynamic analyses of information flow are easily challenged by non-available or obscure code. We present a lightweight mutation-based analysis that systematically mutates dynamic values returned by sensitive sources to assess whether the mutation changes the values passed to sensitive sinks. If so, we found a flow between source and sink. In contrast to existing techniques, mutation-based flow analysis does not attempt to identify the specific path of the flow and is thus resilient to obfuscation. In its evaluation, our MUTAFLOW prototype for Android programs showed that mutation-based flow analysis is a lightweight yet effective complement to existing tools. Compared to the popular FLOWDROID static analysis tool, MUTAFLOW requires less than 10% of source code lines but has similar accuracy; on 20 tested real-world apps, it is able to detect 75 flows that FLOWDROID misses.
- KonferenzbeitragDon’t Program on Fridays! How to Locate Fix-Inducing Changes(Softwaretechnik-Trends Band 25, Heft 2, 2005) Śliwerski, Jacek; Zimmermann, Thomas; Zeller, AndreasAs a software system evolves, programmers make changes that sometimes cause problems. We analyze CVS archives for fix-inducing changes — changes that lead to problems, indicated by fixes. We automatically locate fix-inducing changes by linking a version archive (such as CVS) to a bug database (such as BUGZILLA). In a first investigation of the ECLIPSE history, it turns out that fix-inducing changes are most frequent on Fridays.
- ConferencePaperGenerating Tests that Cover Input Structure(Software Engineering 2021, 2021) Pereira Borges Jr., Nataniel; Havrikov, Nikolas; Zeller, AndreasTo systematically test a program, one needs good inputs—inputs that are valid such that they are not rejected by the program, and inputs that cover as much of the input space as possible in order to reach a maximum of functionality. We present recent techniques to systematically cover input structure. Our k-path algorithm for grammar production [HZ19] systematically covers syntactic elements of the input as well as their combinations. We show how to learn such input structures from graphical user interfaces, notably their interaction language [DBZ19]. Finally, we demonstrate that knowledge bases such as DBPedia can be a reliable source of semantically coherent inputs [Wa20]. All these techniques result in a significantly higher code coverage than state of the art.
- ConferencePaperHeaps'n Leaks: How Heap Snapshots Improve Android Taint Analysis(Software Engineering 2021, 2021) Benz, Manuel; Kristensen, Erik Krogh; Luo, Linghui; Borges Jr., Nataniel P.; Bodden, Eric; Zeller, AndreasThe assessment of information flows is an essential part of analyzing Android apps, and is frequently supported by static taint analysis. Its precision, however, can suffer from the analysis not being able to precisely determine what elements a pointer can (and cannot) point to. Recent advances in static analysis suggest that incorporating dynamic heap snapshots, taken at one point at runtime, can significantly improve general static analysis. In this paper, we investigate to what extent this also holds for taint analysis, and how various design decisions, such as when and how many snapshots are collected during execution, and how exactly they are used, impact soundness and precision. We have extended FlowDroid to incorporate heap snapshots, yielding our prototype Heapster, and evaluated it on DroidMacroBench, a novel benchmark comprising real-world Android apps that we also make available as an artifact. The results show (1) the use of heap snapshots lowers analysis time and memory consumption while increasing precision; (2) a very good trade-off between precision and recall is achieved by a mixed mode in which the analysis falls back to static points-to relations for objects for which no dynamic data was recorded; and (3) while a single heap snapshot (ideally taken at the end of the execution) suffices to improve performance and precision, a better trade-off can be obtained by using multiple snapshots.
- ZeitschriftenartikelHow Design Predicts Failures(Softwaretechnik-Trends Band 26, Heft 2, 2006) Schröter, Adrian; Zimmermann, Thomas; Zeller, AndreasIn an empirical study of 52 ECLIPSE plug-ins, we found that the software design as well as past failure history, can be used to build support vector machines which accurately predict failure-prone components in new programs. Our prediction only requires usage relationships between components, which are typically defined in the design phase; thus, designers can easily explore and assess design alternatives in terms of predicted quality.
- KonferenzbeitragInput Invariants(Software Engineering 2023, 2023) Steinhöfel, Dominic; Zeller, AndreasTo exhaustively test a program, we need inputs that the program does not reject. Such valid inputs must satisfy syntactic and semantic constraints of the input language. Grammar-based fuzzers efficiently produce syntactically valid system inputs but miss context-sensitive semantic constraints. Example semantic properties are length fields or checksums in binary inputs or definition-use constraints for variables in programming languages. We introduce ISLa [SZ22a], a declarative specification language for context-sensitive properties of structured system inputs. An ISLa specification, or input invariant, consists of a context-free grammar and a potentially context-sensitive ISLa constraint. Our ISLa fuzzer produces streams of inputs from invariants. We show that a few ISLa constraints suffice to generate diverse and 100% semantically valid inputs. Additionally, the fuzzer can repair and—preserving semantics—mutate inputs. Provided sample inputs, a program property, or both, our ISLearn prototype mines precise invariants. In follow-up work, we used ISLearn for diagnosing failures: “The heartbleed vulnerability is triggered if length exceeds the length of payload.”
- KonferenzbeitragIsolating Cause-Effect Chains in Computer Systems(Software Engineering 2007 – Fachtagung des GI-Fachbereichs Softwaretechnik, 2007) Neuhaus, Stephan; Zeller, AndreasOne of the major tasks in maintaining software systems is understanding how specific effects came to be. This is especially true for effects that cause major harm, and especially challenging for causes that actively prevent discovery. We introduce Malfor, a system that, for any reliably reproducible and observable effect, isolates the processes that cause the effect. We apply Malfor to intrusion analysis—that is, understanding how an intruder gained access to a system—and come up with cause-effect chains that describe how an attack came to be: “An attacker sent a malicious request to the Web server, which gave him a local shell, by which he gained administrator provileges via a security hole in Perl, and thus installed a new administrator account”. Malfor works by experiments. First, we record the interaction of the system being diagnosed. After the effect (the intrusion) has been detected, we replay the recorded events in slightly different configurations to isolate the processes which were relevant for the effect. While intrusion analysis is among the more spectacular uses of Malfor, the underlying techniques can easily be generalized to arbitrary system behaviors.
- ConferencePaperIsolating Faults in Failure-Inducing Inputs(Software Engineering 2021, 2021) Kirschner, Lukas; Soremekun, Ezekiel; Zeller, AndreasProgram failures are often caused by faulty inputs (e.g. due to data corruption). When an input induces failure, one needs to debug the input data, i.e. isolate faults to obtain valid input data. Typically, debuggers focus on diagnosing faults in the program, rather than the input. This talk instead presents an approach that automatically repairs faults in the input data, without requiring program analysis. In addition, we present empirical data on the causes and prevalence of invalid inputs in practice, we found that four percent of inputs in the wild are invalid. We present a general-purpose algorithm called ddmax that automatically isolates faults in invalid inputs and recovers the maximal valid input data. The aim of ddmax is to (1) identify which parts of the input data prevent processing by the program, and (2) recover as much of the (valuable) input data as possible. Given a program and an invalid input, through experiments, ddmax recovers and repairs as much data as possible. The difference between the original failing input and the “maximized” passing input includes all input fragments that could not be processed, i.e. the fault. This approach is useful for automatically debugging and repairing invalid inputs.
- KonferenzbeitragIt's not a bug, it's a feature: how misclassification impacts bug prediction(Software-engineering and management 2015, 2015) Herzig, Kim; Just, Sascha; Zeller, AndreasThis submission presents work submitted and accepted at the International onference on Software Engineering in 2013 [Hj2013]. In empirical software engineering, it has become common to mine historic data to detect where bugs have occurred in the past, or to predict where they will occur in the future. The accuracy of such models depends on the quality of the data. For example, defect prediction models rely on the accuracy of historic data, such as bug reports.
- «
- 1 (current)
- 2
- 3
- »