Pinned Tweet
Together with @pnolsec and @ms_s3c we just published version 2.0 of Nautilus, our grammar fuzzer. It's now compatible w AFL++, can fuzz binary only targets, supports binary formats and scripting for non context free grammars & much more.
Get it at:
github.com/nautilus-fuzz/nau…
is-eqv.bsky.social retweeted
OGHarn mutationally generates harnesses and uses 3 oracles of behavior to determine both their utility and validity, leading to the discovery of 41 new bugs(with zero false-positive crashes)!
Paper: futures.cs.utah.edu/papers/2…
Source: github.com/FuturesLab/OGHarn
Happy Fuzzing! 🐛
is-eqv.bsky.social retweeted
It's not you, it's the platform. I've been taking a break from Twitter/X. You can follow me at infosec.exchange/@gannimo for unfiltered stuff, linkedin.com/in/mathias-paye… for brags, or bsky.app/profile/gannimo.bsk…
is-eqv.bsky.social retweeted
In the continuing exodus, you may find me at bsky: bsky.app/profile/cestlemieux… or mastodon: mastodon.acm.org/@cestlemieu…
is-eqv.bsky.social retweeted
Dear all: Twitter was great while it lasted, but I no longer want to contribute to X. Future posts will be
* at #Mastodon: mastodon.social/@AndreasZell…
* at #Bluesky: bsky.app/profile/andreaszell…
Goodbye everyone, and see you soon! If you're the last one out, please turn off the lights.
bsky.app/profile/is-eqv.bsky… Feel free to follow over there, will probably become very quite here (also feel free to respond with your bsky handle if I currently follow you here / should follow you there).
is-eqv.bsky.social retweeted
Our LLM work has found an out-of-bounds read in OpenSSL!
CVE-2024-9143 (openssl-library.org/news/sec…) was disclosed recently, which was found by OSS-Fuzz-Gen! This is a pretty proud example of our team showing the promise of leveraging LLMs enable more fuzzing coverage.
Seems like my excitement was misplaced: github.com/FOX-Fuzz/FOX/issu…. If true, the eval is worthless. Which also raises the question: Would a senior researcher make this mistake by accident after saying this xitter.cf/DongdongShe/status/173…? Or is this a pattern? (i.e xitter.cf/AndreasZeller/status/1…)
See also my most recent post for context - the situation isn't ideal, but not critically so and there's reason to be quite hopeful!
xitter.cf/is_eqv/status/18472802…
Thanks @DongdongShe! This is great indeed. While the eval is not following best practices, it is likely still indicative that FOX's actually performs well on many of the targets! Very much looking forward to more replication efforts and see what the final delta is.
Thanks @DongdongShe! This is great indeed. While the eval is not following best practices, it is likely still indicative that FOX's actually performs well on many of the targets! Very much looking forward to more replication efforts and see what the final delta is.
Thanks @is_eqv for raising such an important question for the fuzzing research. Open questions and discussion are the keys to the advancement of fuzzing research. @laosong, @andreafioraldi, I fully agree that results from the third-party fuzzbench infra are more reliable and convincing. Thankfully, we do have results from fuzzbench infra that are consistent with our paper. fuzzbench.com/reports/experi…
Your question: Why not use FuzzBench results in the paper? Are there any hidden dirty tricks/hacks/unfair engineering tricks? How can we trust the results?
Our answer: It takes some engineering effort to build all programs automatically under fuzzbench infra. When building the FOX prototype, we have to fix many compilation issues locally. Due to the time constraint before the paper submission deadline, we locally set up the fuzzing campaign to avoid potential building failure (all code and replication results are open-sourced).
We evaluate FOX under fuzzbench infra after the paper submission. The breakdown performance of FOX vs. AFL++ is consistent with our paper results. Please see the attached plot from the above experimental results under fuzzbench infra. Note that there is still some compilation issue on "proj4" under fuzzbench infra, so the result of FOX is "nan". This compilation failure issue also influences the average ranks of FOX due to the "nan" result on "proj4".
Let me know if you have any questions or concerns about FOX. I am happy to discuss further. We found several fatal bugs regarding the MLFuzz evaluation issue and confirmed with MLFuzz's authors. We are now discussing with MLFuzz's authors and would like to collaborate on the errata of MLFuzz and future adversarial collaboration. We plan to share the experience and lessons of this incident with the community later. Stay tuned.
xitter.cf/is_eqv/status/18470862…
is-eqv.bsky.social retweeted
Thanks @is_eqv for raising such an important question for the fuzzing research. Open questions and discussion are the keys to the advancement of fuzzing research. @laosong, @andreafioraldi, I fully agree that results from the third-party fuzzbench infra are more reliable and convincing. Thankfully, we do have results from fuzzbench infra that are consistent with our paper. fuzzbench.com/reports/experi…
Your question: Why not use FuzzBench results in the paper? Are there any hidden dirty tricks/hacks/unfair engineering tricks? How can we trust the results?
Our answer: It takes some engineering effort to build all programs automatically under fuzzbench infra. When building the FOX prototype, we have to fix many compilation issues locally. Due to the time constraint before the paper submission deadline, we locally set up the fuzzing campaign to avoid potential building failure (all code and replication results are open-sourced).
We evaluate FOX under fuzzbench infra after the paper submission. The breakdown performance of FOX vs. AFL++ is consistent with our paper results. Please see the attached plot from the above experimental results under fuzzbench infra. Note that there is still some compilation issue on "proj4" under fuzzbench infra, so the result of FOX is "nan". This compilation failure issue also influences the average ranks of FOX due to the "nan" result on "proj4".
Let me know if you have any questions or concerns about FOX. I am happy to discuss further. We found several fatal bugs regarding the MLFuzz evaluation issue and confirmed with MLFuzz's authors. We are now discussing with MLFuzz's authors and would like to collaborate on the errata of MLFuzz and future adversarial collaboration. We plan to share the experience and lessons of this incident with the community later. Stay tuned.
xitter.cf/is_eqv/status/18470862…
Seems like my excitement was misplaced: github.com/FOX-Fuzz/FOX/issu…. If true, the eval is worthless. Which also raises the question: Would a senior researcher make this mistake by accident after saying this xitter.cf/DongdongShe/status/173…? Or is this a pattern? (i.e xitter.cf/AndreasZeller/status/1…)
Honestly, I'm pretty excited about this. Both (a) frontier scheduling and (b) branch distance are ideas I've wanted to see implemented robustly for a while, and (c) using a newton-like mutation approach is really clever!
Are general-purpose fuzzing research dead? Our answer is probably no. Check our new fuzzer work FOX.
The awesome fuzzer @aflplusplus is already super-powerful and quite an effective baseline in academics and industry. But there is still room to improve upon. We introduce FOX (CCS 2024), a new general-purpose fuzzer. We formulate the fuzzing as a scholastic online control problem and advance the performance of AFL++ by up to 26.45% in real-world standalone programs and 6.59% in FuzzBench programs. Check our talk at CCS'24 @acm_ccs, fuzzing session 1, Oct 16th, 1:30 PM – 3:00 PM, at Grand Ballroom Salon F.
Paper: arxiv.org/abs/2406.04517
Code: github.com/FOX-Fuzz/FOX
A common problem is:
assert(root.size == sum(c.size for c in root.children)
assert(root.children[0].size == 512)
The fuzzer will likely find inputs that solve the first part, but now it needs to update root.size and child.size at the same time. The newton mutator can solve this.
is-eqv.bsky.social retweeted
Replying to @daveaitel
Perhaps confusingly I’m pretty optimistic about LLMs as a technology. What im pessimistic about is the average LLM commentator ;)
This sounds pretty cool - The old "if only a sufficiently smart compiler existed"-argument notwithstanding, I've always been a fan of trying to exploit more declarative programming languages. This is a pretty cool result!
This quoted post is unavailable.
is-eqv.bsky.social retweeted
There's a point to it. The purpose of money as a signaling/computational medium is underestimated. Market economies are huge distributed computing devices to perform resource allocation that optimizes wellbeing of everyone, weighted by amount of money they have. Heavy ...
is-eqv.bsky.social retweeted
Let’s not forget that people who used NEUZZ had a similar experience to ours regarding its performance. Some examples:
- github.com/Dongdongshe/neuzz…
- xitter.cf/moyix/status/151360853…
- xitter.cf/hugeh0ge/status/183459…
is-eqv.bsky.social retweeted
Replying to @DongdongShe
@DongdongShe You seem happy enough to communicate in the public channel: you’re the one who took this to Twitter and shared private conversations.
If you’re going to share emails, might as well do so in full and not cherry-pick:
Ep5. Rebuttal MLFuzz
Thanks Irina’s response. We never heard back from you and @AndreasZeller since last month when we sent the last email to ask if you guys were willing to write an errata of MLFuzz to acknowledge the bugs and wrong conclusion. So I am happy to communicate with you in the public channel about this issue and clarify the misleading conclusions in your paper MLFuzz in front of the fuzzing community.
Our first email pointed out 4 bugs in MLFuzz and we showed that if you fixed the 4 bugs you can successfully reproduce our results. We also provide a fixed version of your code and preliminary results on 4 FuzzBench programs. Your first response confirmed 3 bugs but refused to acknowledge the most severe one – an error in training data collection. For any ML model, garbage in, garbage out. If you manipulate the training data distribution, you can cook any arbitrary poor results for an ML model.
Why are you reluctant to fix the training data collection error? Instead, you insist on running NEUZZ with the WRONG training data and cooking invalid results even though we already notified you of this issue. We suspect maybe that’s the only way to keep reproducing your wrong experiment results and avoid acknowledging your error in MLFuzz.
Your research conduct raised a serious issue about how to properly reproduce fuzzing performance in the Fuzzing community. Devil’s advice: blindly, deliberately or stealthily run it with WRONG settings or patch it with a few bugs and claim its performance does not hold? Only an ill-configured fuzzer is a good baseline fuzzer.
We think a fair and scientific way to reproduce/revisit a fuzzer should ensure running a fuzzer properly as the original paper did, rather than free-style wrong settings and bug injections.
The fact is you guys wrote buggy code (you confirmed in the email) and cooked invalid results and wrong conclusions published in a top-tier conference @FSEconf 2023. We wrote a rebuttal to point out 4 fatal bugs in your code and wrong conclusions.
A responsible and professional response should directly address our questions about the 4 fatal bugs and wrong conclusions. But your response discussed the inconsistent performance number issue of NEUZZ (due to a different metric choice), the benchmark, seed corpus, IID issue of MLFuzz. They are research questions about NEUZZ and MLFuzz, but they are not the topic of this post: MLFuzz rebuttal.
They can only shift the audience's attention but cannot fix the bugs and errors in MLFuzz. I promise I will address every question in your response in a separate post on X, but not in this one. Stay tuned! @is_eqv @moyix @thorstenholz @mboehme_
























