Linux: Beep Command Can Be Used to Probe for the Presence of Sensitive Files (bleepingcomputer.com)

Catalin Cimpanu, writing for BleepingComputer: A vulnerability in the "beep" package that comes pre-installed with Debian and Ubuntu distros allows an attacker to probe for the presence of files on a computer, even those owned by root users, which are supposed to be secret and inaccessible. The vulnerability, tracked as CVE-2018-0492, has been fixed in recent versions of Debian and Ubuntu (Debian-based OS). At its core, the bug is a race condition in the beep utility that allows the OS to emit a "beep" sound whenever it is deemed necessary. Security researchers have discovered a race condition in the beep package that allows an attacker to elevate his code to root-level access.

Comments

Article ist not correct

[messju]

Beep is not pre-installed on Debian GNU/Linux.

Re:beep boop root

[TheRaven64]

Right? About the only thing worse would be a kernel vulnerability in something silly like fonts

Windows and Linux have both had font handling vulnerabilities. The difference is that in Windows they were in the kernel, whereas in Linux they were in X11, which ran with root privilege and could open /dev/kmem and directly modify kernel memory.

The beep vulnerability makes a lot of sense, actually.

No it doesn't. All *NIX operating systems provide standard UNIX file permissions on device nodes and accessing /dev/dsp or the device for the internal speaker to a group is trivial. Most modern *NIX systems provide ACLs, so you can provide finer-grained access. Most modern *NIX systems even provide access control frameworks that let you grant access on a {program, file} pair, rather than, a {user, file} pair, so you could grant access to the device to the beep program running at any user, but not grant any other rights to the program or the user. These vulnerabilities are in no way intrinsic to the beep program, they are related to how the beep program is installed.

And rooted from the patch, too

[DrYak]

"Linux can be rooted by a command that makes your computer beep? That's fucking idiotic, man..."

And the patch that supposedly fixes the bug contains this gem :

--- /dev/null 2018-13-37 13:37:37.000000000 +0100
+++ b/beep.c 2018-13-37 13:38:38.000000000 +0100
1337a
1,112d
!id>~/pwn.lol;beep # 13-21 12:53:21.000000000 +0100
.

Which is supposed to be an exploit of patch:
according to that source, patch supports diff written in ed scripts (you, know the one editor that is supposed to be the punch line of every "VI vs EMACS" flamewar)
and ed in turn has "! command" to execute commands.

So yes, even the patch fixing the "beep" exploit can be exploited in turn and root the system too (... of any admin careless enough to run the build of the patched package on the bare system instead of inside some container and as a non-root user).

---

Back to beep itself :
- https://sigint.sh/#/holeybeep - a good source which analyzes how beep is exploitable (basically signal handler called at the exact wrong time, while performing a switcharoo on symlink target, between the console that gets opened on each beep, and the target file that gets opened when the signal kills the audio)
- https://github.com/johnath/bee... upstream audio.

Re:I find it ironic...

[Anonymous Coward]

Your comment tells me that you probably don't understand the "putchar('\007')" reference.

The "bell" command is so primitive that it's a BIOS function. There's no code to write. It's already in there. Even from the DOS 1.0 command line you can type "echo ^G" and it works. (That's the control key plus the letter G, for the younger kids in the crowd)

It should be so simple that regardless of how many layers of code you pile on top, security issues of ANY form should be impossible, But, alas, code bloat and overly complex implementations have brought us to this place. You can't even trust a beep.

Fonts on UNIX

[DrYak]

The difference is that in Windows they were in the kernel, whereas in Linux they were in X11, which ran with root privilege and could open /dev/kmem and directly modify kernel memory.

Maybe a couple of decades ago.

Since then:
- in some distant past, font rendering on Unix was offloaded to a separate X Font Server that communicate over a socket, and didn't need it self to be root to write to the framebuffer.
- in a more recent past , font rendering was moved out of the X server, and into the client.

No it doesn't. All *NIX operating systems provide standard UNIX file permissions on device nodes and accessing /dev/dsp or the device for the internal speaker to a group is trivial.

In this case, that's the console/VT or event device (basically beep is good old "\a" bell, but on steroids, i.e.: with ioctl/writes to precisely tune the beep).
It doesn't use any audio device (no /dev/dsp).

That's indeed stupid as there are methods to give access of those to the currently loged-in user (If I'm not mistaken, basically the same work that has been done to run X11 on any non-dinosaur distros)

That's exactly what is abused by some exploits (source) :
have a symlink point to an event device (the king that is controlled by writing instead of ioctl) start a "beep" command (which will open the symlink for writing as root on each played sound), then at the perfect time reroute the symlink send a kill signal - the signal handle will try to mute the speaker (by again opening the symlink for writing), but is now writing the parameters in the target file instead of the event device.