[anonymouzz]

I'd be interested. The two still offending tools (spell and f77) sound super rarely used these days. I think it's fair to compare samples of commonly used tools in 1995 with samples of commonly used tools in 2018 even if those samples are widely different. This would be more related to the change in the probability that an average user sees a crash.

[tyoma]

This was on Ubuntu 14.04 -- I know 14.04 is dated, but its the last image I had running from the previous tests :).

I wrote some stupidly simple bash to just pipe output of fuzz to every executable in /usr/bin/, with a 10 second timeout. This was only meant as a quick experiment, so there was no consideration of proper arguments (e.g. some applications may only read files and not stdin).

The following applications produced a core dump:

  /usr/bin/icontopbm
  /usr/bin/pnmmontage
  /usr/bin/pnmpsnr
  /usr/bin/rletopnm
  /usr/bin/nslookup
  /usr/bin/aleph
  /usr/bin/acpi_listen
  /usr/bin/info
  /usr/bin/xetex

[fanf2]

Is nslookup from bind9 or some other package? I think ISC might be interested in fixing the crash.

[cat199]

f77/f2c - you'd be surprised

often gets pulled in if other fortran (gfortran usually on a linux) is not available when building certain numerical software which in turn relies on netlib.org open fortran code, which in turn is written in fortran77

these libraries are give-or-take at the core of tons of numerical/scientific computing software, and likely used by many other programs needing heavy math

[a-dub]

Translators are interesting here. In this case it looks like it's just falling during translation (and a fast failure at that). An interesting question would be if there were a structured input (ie; valid Fortran) that result in the emission of unsafe C.

[tyoma]

Agree. Also a random input generation tool should really be run multiple times against each target, etc.