Author here.<p>The predictions and insights from the two papers were fascinating to read with 30 years of hindsight.<p>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.
The Debian discussion for the ul/glibc issue:<p><a href="https://lists.debian.org/debian-glibc/2016/09/msg00177.html" rel="nofollow">https://lists.debian.org/debian-glibc/2016/09/msg00177.html</a><p>mentions this bug:<p><a href="https://sourceware.org/bugzilla/show_bug.cgi?id=20632" rel="nofollow">https://sourceware.org/bugzilla/show_bug.cgi?id=20632</a><p>"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."<p>If that's true, I can't help wondering if an exploit for this is already sitting in some blackhat's tool box somewhere.
The real bomb-shell here that I find terrifying, is that there is still an open and (likely) exploitable bug in glibc that has been around for years and isn't getting attention. glibc is <i>everywhere</i> and used by almost <i>everything</i>. If you program in almost any modern language like ruby, node.js, python, java, C, C++, or more, you are calling functions in glibc.<p>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.