Share this page!

Marcel Böhme Profile picture
Twitter logo
Apr 23 • 5 tweets • 4 min read
The FUZZING'22 Workshop is organized by
* Baishakhi Ray (@Columbia)
* Cristian Cadar (@ImperialCollege)
* László Szekeres (@Google)
* Marcel Böhme (#MPI_SP)

Artifact Evaluation Committee Chair (Stage 2)
* Yannic Noller (@NUSComputing)
Baishakhi (@baishakhir) is well-known for her investigation of AI4Fuzzing & Fuzzing4AI. Generally, she wants to improve software reliability & developers' productivity. Her research excellence has been recognized by an NSF CAREER, several Best Papers, and industry awards.
Cristian Cadar (@c_cadar) is the world leading researcher in symbolic execution and super well-known for @KLEEsymex. Cristian is an ERC Consolidator, an ACM Distinguished Member, and received many, many awards, most recently the IEEE CS TCSE New Directions Award.
László Szekeres (@lszekeres) is passionate about software security where he wages Eternal War in Memory (SoK). He develops tools & infrastructure for protecting against security bugs, like AFL's LLVM mode or the Fuzzbench fuzzer evaluation platform.
Yannic Noller (@yannicnoller) works on fuzzing and automated program repair and is interested in software reliability, trustworthiness, and security. Yannic was also named as Distinguished Artifact Reviewer at ISSTA'21 and will organize artifact evaluation for our Stage 2.

• • •

Missing some Tweet in this thread? You can try to force a refresh
　

Keep Current with Marcel Böhme

Marcel Böhme Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @mboehme_

Marcel Böhme Profile picture
Apr 23
There are tremendous opportunities to improve the way we disseminate research in Computer Science. Our current approach is to ask three experts to decide: Accept or Reject.

Here is what's wrong with this publication model 🧵

1/n
1. Providing feedback when the work has already been completed is utterly ineffective. What do we do if reviewers point out flaws in the eval or experiment design? Cycle it through our confs & journals until we are lucky. There is no consistency among reviewer expectations.

2/n
2. Strong focus on results. Papers with ε-novelty are accepted if the results are super-strong even if there is no convincing evidence that the results are due to the paper's contribution. This focus leads to duplicated efforts & overclaims, and ultimately impedes progress.

3/n
Read 10 tweets
Marcel Böhme Profile picture
Apr 7, 2021
I asked #AcademicChatter about incentives & processes behind paper machines (i.e., researchers publishing top-venue papers at unusually high rates).

This is what I learned 🧵

TL;DR: Any incentive emerges from our community values. It is not "them" who needs to change. It is us. Image
It was tremendously exciting to get so many perspectives from so many junior and senior researchers across different disciplines. This was only a random curiosity of mine but it seemed to hit a nerve. I loved the positive, constructive tone in the thread.

Let's get started.
2/12
Some of you raised serious concerns about academic misconduct. However, to keep the discussion constructive, let's assume researcher integrity. We'll explore alternative explanations and processes below.
3/12
Read 14 tweets
Marcel Böhme Profile picture
Mar 30, 2021
👇 Fuzzing Papers with Code 👇

In 2020, only 35 of 60 fuzzing papers published the code together with the paper. In 2021, let's do better! #reproducibility

Data from wcventure.github.io/FuzzingPaper/
Conferences: CCS, NDSS, S&P, USENIX Sec, ICSE, ESEC/FSE, ISSTA, ASE, ASIACCS, ICST.
1/5
Alphabetically,
* github.com/aflnet/aflnet
* github.com/aflplusplus/AF…
* github.com/andreafioraldi…
* github.com/assist-project…
* github.com/duytai/sfuzz
* github.com/fau-inf2/StarS…
* github.com/hexhive/USBFuzz
* github.com/hexhive/FuzzGen
* github.com/hexhive/retrow…
* github.com/hub-se/MoFuzz
2/5
* github.com/iromise/fans
* github.com/michael-emmi/c…
* github.com/moonmight-stei…
* github.com/piano-man/DPIF…
* github.com/practical-form…
* github.com/rub-syssec/cup…
* github.com/rub-syssec/hyp…
* github.com/rub-syssec/ijon
* github.com/seemoo-lab/fra…
* github.com/sslab-gatech/D…
3/5
Read 5 tweets
Marcel Böhme Profile picture
Sep 5, 2020
[#Fuzzing Evaluation] How do we know which fuzzer finds the largest number of important bugs within a reasonable time in software that we care about?

A commentary on @gamozolabs' perspective.
(Verdict: Strong accept).
YES! We need to present our plots on a log-x-scale. Why? mboehme.github.io/paper/FSE20.Em…
Two fuzzers. Both achieve the same coverage eventually. Yet, one performs really well at the beginning while the other performs really well in the long run. (What is a reasonable time budget? 🤔)
Nice! I agree, comparing *time-to-same-coverage* provides more information about fuzzer efficiency than comparing coverage-at-a-given-time.
Read 10 tweets
Marcel Böhme Profile picture
Jul 2, 2020
For my new followers, my research group is interested in techniques that make machines attack other machines with maximal efficiency. All our tools are open-source, so people can use them to identify security bugs before they are exploited.

This is how it all started.
My first technical paper introduced a technique that could, in principle, *prove* that no bug was introduced by a new code commit [ICSE'13]. This was also the first of several symbolic execution-based whitebox fuzzers [FSE'13, ASE'16, ICSE'20].

mboehme.github.io/paper/ICSE13.p…
Yet, something was amiss. Even a simple random input generator could outperform my most effective whitebox fuzzer if it generated inputs fast enough. To understand why, we modelled fuzzing as a sampling process and proved some bounds [FSE'14, TSE'15].

mboehme.github.io/paper/TSE15.pdf
Read 13 tweets
Marcel Böhme Profile picture
Sep 24, 2019
Kostya's keynote: LibFuzzer hasn't found new bugs in <big software companie>'s library. We didn't know why. Later we got a note that they are now using LibFuzzer during regression testing in CI and that it prevented 3 vulns from reaching to production.
In Chrome, libFuzzer found 4k bugs and 800 vulns. In OSS-Fuzz, libFuzzer found 2.4k bugs (AFL found 500 bugs) over the last three years.

@kayseesee #fuzzing #shonan
@kayseesee Fuzz-driven Development: Write your fuzz targets first.
Read 7 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(