The predictions and insights from the two papers were fascinating to read with 30 years of hindsight.
I also ran the random input generating “fuzz” tool against everything in /usr/bin (after some very minor fixes to get fuzz to build using ANSI C89). I can post the results later if there is interest.
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/xetexoften 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
https://lists.debian.org/debian-glibc/2016/09/msg00177.html
mentions this bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=20632
"This seems quite exploitable to me: we end up overwriting a function pointer that malloc invokes. If an attacker can invoke the process with stderr closed (easy to do from a shell), and can control what text the process outputs to stderr, the attacker can execute arbitrary code."
If that's true, I can't help wondering if an exploit for this is already sitting in some blackhat's tool box somewhere.
Note: Unless you use an alternative libc implementation such as musl, which is standard on things like Alpine Linux for example. However glibc is by far most common.
The bug description certainly makes it sound very serious. If its not fixed in upstream, it at least seems fixed at the distribution level since Ubuntu 18.04 and newer don't suffer from the issue. Or if they do, it can't be reached via the same code in ul.
Also, I don't know how much of glibc is used by openjdk, but potentially not a lot because the jvm wants to behave the same on all platforms, so they don't want to rely on behaviors of the libc.