This page contains a number of open projects that are currently available in our group. See here for organizational info.
Bachelor Projects
Project Description | Daily Supervisor |
Fuzzing with conditional targeting Goal: Improve fuzzing by letting the fuzzer select/ schedule which branch conditions should be solved | |
Economics of bug finding Goal: How can modern fuzzing tools be used in a cost-efficient way. How should one approach finding bugs, given a certain budget (e.g., in a cloud setting). Bonus: Build a framework that automatically deploys an optimal setup in AWS, Azure, GCP, etc. | |
Checkpoint Fuzzing Goal: Improve fuzzing performance by using checkpointing to eliminate the need to restart the target process. Bonus: Get it working for OS Kernel/ Hypervisor fuzzing | Sebastian |
Build OS Goal: build minimal OS from scratch that does something interesting. Minimally, the students should implement some basic functionality, e.g., bring up MMU, but the goal is to do something more interesting: target a new architecture or use a new feature. Bonus: some novel feature | |
Microarchitectural research OS Goal: Build a research OS similar to https://gamozolabs.github.io/metrology/2019/08/19/sushi_roll.html Bonus: Evaluate how different hardware features interact with e.g., speculative execution | |
Hard cases for Fuzzing Goal:Identify hard cases for current fuzzers and create a unit-test-like suite to evaluate Fuzzers Bonus:Write fuzzing strategies that can solve these cases | Sebastian |
Bug/ fuzzing ground truth using commit logs in OSS Goal:Assess the ground truth of bugs found by fuzzers based on real-world Open Source Software (see https://arxiv.org/pdf/1808.09700.pdf Section 7.2), based on git diffs. Bonus:Link these bugs to the corresponding real CVEs to build a database of real-world bugs. Assess how existing memory safety mechanisms detect these vulnerabilities. | Sebastian |
Fuzzing analysis Goal: Analyse how long it takes for different fuzzers from reaching a BB to triggering a bug in that BB. Probably different projects for different types of bug. Bonus:Speed this up? | |
Fuzzing generalization Goal:adapt some fuzzer to handle a new class of applications (e.g., network servers, multiple input files, configuration). Bonus: proper evaluation of an interesting dataset | |
Anti fuzz Goal: software vendors may want to using fuzzing themselves to find bugs during the testing phase, but when they finally release the binary code, make it as hard as possible for *others* to fuzz the program. This is known as anti-fuzz. The idea is that you transform the program in a way that makes it very hard for automated fuzzers to make much progress. The goal is to build a translator (compiler or binary translator) that transforms a program in this way. Bonus: target multiple types of fuzzer | |
Reproducibility of research results Goal:look at the code released by researchers. Evaluate if it works. Do some statistics | |
Meta-meta research Goal: grep for interesting features in published papers. E.g., how many papers use SPEC, etc. How often do ppl push papers on arxiv prior to publishing papers? Self-citation, citation rings? | |
Influencers: Goal:how influential are certain researchers on specific research directions? |
LLVM-based projects
SoftBound: Highly Compatible and Complete Spatial Memory Safety for C
http://www.cis.upenn.edu/acg/papers/pldi09_softbound.pdf
Goal: Implement a basic version of SoftBound that supports a some real-world C programs, including an in-memory lookup table.
Bonus: Optimize the checks using Intel MPX, a new hardware feature.
CETS: Compiler-Enforced Temporal Safety for C
http://www.cis.upenn.edu/acg/papers/ismm10_cets.pdf
Goal: Implement a basic version of CETS that creates metadata and locks for every allocation, that works on some real-world C programs.
Bonus: Eliminate checks on the hot path to improve performance, similar to ASAP [1]
[1] http://dslab.epfl.ch/proj/asap/
PAriCheck: An Efficient Pointer Arithmetic Checker for C Programs
http://www.fort-knox.org/files/paricheck.pdf
Goal: Implement a basic version that enforces bounds checking on the stack and heap by tagging each chunk of memory with a tag, and checking that the tag before and after pointer arithmetic is the same.
Bonus: Optimize the approach by using variable-sized granularity of the tags, utilizing a memory layout similar to Baggy Bounds[1] or Low-Fat Pointers[2]
[1] https://www.usenix.org/legacy/event/sec09/tech/full_papers/akritidis.pdf
[2] http://www.comp.nus.edu.sg/~gregory/papers/cc16lowfatptrs.pdf
AddressSanitizer: A Fast Address Sanity Checker
https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf
Goal: Implement redzones around each object on the heap, using shadow memory to record a per-byte accessibility status, and implement checks on every memory access.
Bonus: Eliminate checks on the hot path to improve performance, similar to ASAP [1]
Bonus: Allow for bigger redzones without wasting physical memory by using page aliasing tricks [2], mapping multiple virtual pages to a single physical page.
Bonus: Eliminate the shadow memory lookup for checks by adding poison values in the redzones [3].
[1] http://dslab.epfl.ch/proj/asap/
[2] https://pdfs.semanticscholar.org/46b1/9795bbda3b8c0c3e02896482fe61bb2943bc.pdf
[3] http://seclab.cs.sunysb.edu/seclab/pubs/lbc.pdf
SGXBounds: Memory Safety for Shielded Execution
http://se.inf.tu-dresden.de/pubs/papers/sgxbounds2017.pdf
Goal: Implement a simplified version of SGXBounds that encodes the upper bound of each object in the upper bits of the pointer. MidFat[1] can serve as a starting point for the pointer tagging implementation.
Bonus: Eliminate checks on the hot path to improve performance, similar to ASAP [2]
[1 ]http://www.sharcs-project.eu/m/documents/papers/a09-kroes.pdf[2] http://dslab.epfl.ch/proj/asap/
Readactor: Practical Code Randomization Resilient to Memory Disclosure
https://pdfs.semanticscholar.org/5011/7210fbb7a8ce28ba503280f3c65fdc029ec7.pdf
Goal: Implement Readactor’s code randomization policies in LLVM: function-level randomization and code pointer hiding in particular.
Bonus: Implement execute-only memory with a mechanism of your choice.
CodeArmor: Virtualizing the Code Space to Counter Disclosure Attacks
http://www.cs.vu.nl/~giuffrida/papers/codearmor-eurosp-2017.pdf
Goal: Implement a simplified CodeArmor-like system in LLVM, with support for single-threaded programs and re-randomization triggered programmatically.
Bonus: Support multithreaded re-randomization with per-thread code segments.
The Performance Cost of Shadow Stacks and Stack Canaries
https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43809.pdf
Goal: Implement a parallel shadow stack in LLVM.
Bonus: Selectively instrument only functions that are prone to buffer overflows (e.g.,with buffer local variables).
Code-Pointer Integrity
https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-kuznetsov.pdf
Goal: Implement CPS for regular code pointers in LLVM.
Bonus: Support VTable pointers for C++ programs as well and protect the safe region.
ASLR-Guard: Stopping Address Space Leakage for Code Reuse Attacks
http://www-users.cs.umn.edu/~kjlu/papers/aslrguard.pdf
Goal: Implement ASLR-Guard’s function pointer encryption mechanism in LLVM.
Bonus: Extend the scheme to return addresses.
CCFI: Cryptographically Enforced Control Flow Integrity
http://www.scs.stanford.edu/~dm/home/papers/mashtizadeh:ccfi.pdf
Goal: Implement basic CCFI for function pointers in LLVM.
Bonus: Implement type-based CFI policies on top of your basic implementation.
Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM
https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-tice.pdf
Goal: Implement IFCC in LLVM.
Bonus: Improve type accuracy by using debug symbol (dwarf) information support in LLVM.
kRˆX: Comprehensive Kernel Protection against Just-In-Time Code Reuse
https://www1.cs.columbia.edu/~angelos/Papers/2017/krx.pdf
Goal: Implement kR^X’s function- and basic-block-level permutation in LLVM for the kernel.
Bonus: Implement global and local variable permutation as well.
Literature Studies
Master Projects
We have too many ever-changing project ideas to discuss here. Please contact us if you are interested in our research-oriented Master projects.
Individual Projects
These are smaller projects for courses such as Android Lab (XM_40011), Individual Systems Practical (XM_405088), PDCS Programming Project (XM_405054), etc. Usually 6 or 12 ECTS. These projects can be a stepping-stone to a larger Master Project.