Elektrine lite

← Feed

@tef@mastodon.social

Post #1009008

2026-04-08 13:44 UTC

finding myself repeating "fuzzers are stochastic, with enough cpu time you will always find a bug, results are a usually demonstration of resources not algorithms" like, hacking, along with spam and fraud are the sorts of activities where things only need to work 0.1% of the time to be successful it isn't a demonstration of clever code or tooling but the uncompromising effectiveness of sheer brute force heh

Replies (7)

  • @pozorvlak@mathstodon.xyz 2026-04-08 13:50

    @tef dude, this is cope. What you say is all true, but they have (apparently) dramatically reduced the resources required to find and exploit vulnerabilities which resisted many rounds of previous investigation. This is a big deal.

    Open ##1919854

  • @tef i don't think this is correct, actually. afl (when it got introduced) has massively reduced the amount of resources because it is coverage-guided

    Open ##1919857

  • @tef Seriously! I've been reading the bugs they found - and the reason these are old bugs is that they're bugs that any linter would have found but no one bothered to run against ancient working code.

    Open ##1919876

  • @atax1a@infosec.exchange 2026-04-08 15:47

    @tef @rootwyrm and the slop companies are running a protection racket in open source: "nice project you got there. accept our slop vulnerability fixes and our slop triage for the slop reports, or else" and people are knuckling under (:

    Open ##1919877

  • @gabrielesvelto@mas.to 2026-04-08 19:09

    @tef as they say, in all things computing if brute force doesn't work it's because you're not using enough of it

    Open ##1919879

  • @addison@nothing-ever.works 2026-04-08 19:58

    @tef@mastodon.social of course, the cleverness of that brute force is a factor This post brought to you by someone who's entire PhD rests on fuzzing

    Open ##1919880

  • @lispi314@udongein.xyz 2026-04-08 21:02

    @tef > with enough cpu time you will always find a bug, results are a usually demonstration of resources not algorithms" I'm inclined to think that's largely a reflection of bad design (either of the program, tools or language). If the program can enter invalid states, it supports logical operations to put it in such a state (unless you're fuzzing for hardware flaws, at which point the program is incidental and barely if at all related). That's bad design (or implementation thereof, it's quite possible to have a good design and screw up the coding part) unless it specifically must support arbitrary operations for its intended purpose. Some languages make proper implementation of a design harder though, such that running fuzzers can be useful when for whatever reason proper semantics for the intended operation cannot be directly encoded. (The real solution is discontinuing use of those languages or use without tooling that provides such properties.)

    Open ##1919881