On January 13 at 10:00, Marcel Böhme, co-author of the Fuzzing Book and an eminent fuzzing researcher, will visit CISPA. Feel free to join us for his talk. (Our regular lecture will still take place at 14:15.) Details on Marcel's talk below:

Marcel Böhme: Automatic Software Security at Scale
January 13, 10:00 - 11:30, CISPA Stuhlsatzenhaus Lecture Hall

Abstract. The security of our software systems has never been more important. Just this week, a Principal Engineer at Google announced that a coding agent created in a few hours what her entire team spent one year to build. Soon, our software systems will rapidly change and evolve with minimal human intervention in reaction to user needs and requirements. Yet, as we are grappling with LLM hallucinations and trustworthiness, how do we ensure that our systems today and those “machine-developed” systems of the future are reliable and secure?
In this talk, we will explore the exciting opportunities and the fundamental limitations of automatic security analysis and testing techniques. We will discuss why only an exponential increase in the number of machines will give us at most a linear increase in the number of bugs that a security testing tool can find and why, once we have started, we can never really stop running automatic, continuous security testing. We will discuss the degree to which testing can show the absence of bugs and extend our statistical approach to a more general paradigm called empirical program analysis which scales to the machine-developed software systems of the future.

Bio. Marcel Böhme is a faculty member at the Max Planck Institute for Security and Privacy (MPI-SP) where he leads the Software Security group. He is the elected Spokesperson for Research Group Leaders at the Chemistry, Physics, and Technology Section of the Max Planck Society, a Guest Editor-in-Chief and Associate Editor for the ACM TOSEM, the flagship journal in Software Engineering, and on the steering committees of ASE and ISSTA, two of the largest, premier conferences in his area. He was named 2025 ACM Distinguished Member and won a 2024 ERC Consolidator grant, a 2022 NUS Outstanding Young Computing Alumni Award, a 2019 ARC DECRA (Australia's ERC Starting), and several ACM Distinguished Paper awards, spotlights, and highlights at the premier publication venues for security and software engineering. Marcel received his PhD at the National University of Singapore. To find out more about his group and their research, head over to: https://mpi-softsec.github.io.

I was made aware of two distinct bugs with the project setup, and found one cheating avenue, all of which was fixed by a commit that was just pushed to the repositories of all students that have already accepted the project 1 (please run git pull!) — students who have not yet accepted the project will automatically get the newest version. Here are the changes in detail:

• Previously, the runtime of any logic run at the top level of fuzzer.py (or any other file imported from there) was not accounted. This means that in principle, students would have been able to use an arbitrary amount of runtime to pre-compute inputs, such that their entire hour of running the target could be spent in the target, even when using a very slow fuzzer. This would obviously be considered cheating. We have changed the behavior as follows: The setup logic is now times. If it takes longer than 5 minutes, any additional time is deducted from your fuzzing budget. Some examples:
  • If your setup logic takes 3 seconds, you will get 60 minutes of fuzzing.
  • If your setup logic takes 4.5 minutes, you will still get 60 minutes of fuzzing.
  • If your setup logic takes 8 (5 + 3 extra) minutes, you will only get 57 (60 - 3) minutes of fuzzing.
• On Windows systems, git has (as is normal for its operation) converted the line endings of non-binary files to CRLF, instead of the LF used in UNIX, when you cloned the repository. This is done to allow ordinary Windows programs to change the files. The line endings are changed back once the changes are pulled to a UNIX system. However, on a Windows machine, some files (specifically apt-packages.txt and run_and_get_coverage.sh) are simply copied from the Windows host to the Ubuntu Docker image, without the intermediate fixes through git. This lead to failures when trying to build the Docker images on Windows systems, since the extra characters are not legal in those places in Ubuntu. To fix this, the line endings are now manually converted in the Dockerfile.
• If your fuzzer called some other process that either (a) calls the default system-wide Python interpreter, or (b) is only available as a Python dependency, this would previously fail, because the virtual environment, into which all Python dependencies are installed, was not correctly activated. This should now be fixed.

If you have any questions regarding these changes, please ask them in the forum. I would also like to thank all the students that have reported these bugs and helped me find fixes. Enjoy your fuzzing!

We have just noticed that we made a mistake with the deadline for Assignment 6, specifying December 16th instead of December 9th. To avoid any potential confusion, we will not be changing the deadline for Assignment 6. We will collect your solutions on December 16th. However, we still encourage you to complete Assignment 6 this week, as we will release Assignment 7 next week. As usual, you will have 7 days to solve it. So, both solutions for Assignments 6 and 7 will be collected on December 16th. Happy fuzzing!

After some questions and further evaluation by us, we found that project 1 has a shortcut that we deem unfair: If you happened to find a set of very good seed inputs (and there are plenty of those lists out there), you were basically guaranteed to get the maximum grade, even without having to write a fuzzer. We have therefore split the project 1 evaluation into two parts: One with no seeds, and one with a small set of high-quality seeds provided by us. This will provide a more even playing ground for everybody.

For those of you who previously accepted the assignment: I pushed the changes to your repository directly. Please run git pull. For those of you who have not: You will get the updated instructions directly, once you do accept the assignment.

Refer to the README for the updated instructions and rules. Please re-read the entire README, as multiple things have changed. We are sorry about the inconvenience, particularly to students who have already discovered this and put in some work to find good seeds. If you have any questions regarding the new rules, please ask in the forum.