Seeking new PhD student as well as MS thesis and graduate/undergraduate project students.
The project investigates the full patching workflow for both Java and C/C++, from when the security vulnerability is detected and a reproducible exploit is demonstrated, through testing candidate patches, to when users have validated and applied the released patch in production. Developer productivity will be improved since constructing, executing and checking exploit test cases will be automated; the productivity of the application’s administrators will be improved since they will spend less time painstakingly validating patches by hand and more time directly benefiting their business. The application’s users will more rapidly be protected from a vulnerable application threatening their own security and privacy.
We build on record/replay technology, which already supports deterministic bug reproduction and replay of the originally recorded log after very restricted changes, such as inserting print statements, recompiling with instrumentation and reconfiguring to increase verbosity, that do not affect application state. However, unrestricted changes constituting a patch – which typically do affect application state – are often sufficiently modest that the modified application can still be replayed with small mutations to the original record/replay log. In particular, static and dynamic analyses, such as slicing, data dependency graphs, and taint tracking, can rule out potential log mutations that would be unsound and suggest other prospective log mutations consistent with the code changes. Then the replayer can skip over no longer relevant log entries and “go live” for new/replaced library and system calls, while reusing unaffected data from the recorded log.
In addition to longer-term participants, we are currently looking for one or more undergraduate/MS project students to perform a relatively short-term project for academic credit: We would like to convert the open-source rr record/replay system (https://rr-project.org/) to directly support Java programs. rr already supports Java applications running on top of the JVM, but it records and replays all the activities of the underlying JVM rather than just the Java application, which is inefficient and makes it difficult to reason about the Java application state, needed to enable mutable replay. We will train you in the concepts of record/replay. Your job will be to study how rr works internally, to evaluate the feasibility of such a conversion and determine what, specifically, would need to be changed.
Other one-semester projects can be defined for interested project students.
To learn more, please contact Prof. Kaiser, firstname.lastname@example.org.