Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security Linux

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

Posted by msmash from the a-quiet-place dept.
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.
This discussion has been archived. No new comments can be posted.

Linux: Beep Command Can Be Used to Probe for the Presence of Sensitive Files More

Linux: Beep Command Can Be Used to Probe for the Presence of Sensitive Files

Comments Filter:

  • bleep (Score:5, Funny)

    by Chaldean42 ( 1346793 ) on Tuesday April 10, 2018 @10:23AM (#56412383)
    Anyone else find it ironic that this comes from bleepingcomputer.com?

  • beep boop root (Score:1)

    by Anonymous Coward

    Urg... this'll get some flack from the Windows fanboys.

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

    • Right? About the only thing worse would be a kernel vulnerability in something silly like fonts [blogspot.com]...

      The beep vulnerability makes a lot of sense, actually. Related to this update, I recently learned that the ubiquitous beep used to be driven by reprogramming the system clock [microsoft.com]. Naturally, that kind of hardware access is something that should be a system administrator function, restricted to root on *nix systems. It would make sense, then, that any vulnerability there would likely be a privilege escalation.

      • Re:beep boop root (Score:4, Informative)

        by TheRaven64 ( 641858 ) on Tuesday April 10, 2018 @11:10AM (#56412701) Journal

        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.

        • Fonts on UNIX (Score:5, Informative)

          by DrYak ( 748999 ) on Tuesday April 10, 2018 @12:18PM (#56413229) Homepage

          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 [wikipedia.org] 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 [github.com] (source [sigint.sh]) :
          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.

      • Re: (Score:2)

        by tlhIngan ( 30335 )

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

        The beep vulnerability makes a lot of sense, actually. Related to this update, I recently learned that the ubiquitous beep used to be driven by reprogramming the system clock. Naturally, that kind of hardware access is something that should be a system administrator function, restricted to root on *nix systems. It would make sense, then, that any vulnerability there would likely be a privilege escalation.

        Font h

        • Both points there are exactly what I was alluding to... Modern computing is a lot more complicated than it seems. It's amazing how much of technology is hacked together with duct tape and baling wire to make it work, and it's silly for anyone to throw stones in a city full of glass houses.

    • And rooted from the patch, too (Score:5, Informative)

      by DrYak ( 748999 ) on Tuesday April 10, 2018 @11:49AM (#56413003) Homepage

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

      And the patch [holeybeep.ninja] 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 [seclists.org]:
      according to that source, patch supports diff written in ed [die.net] 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 [sigint.sh] - 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... [github.com] upstream audio.

  • Article ist not correct (Score:4, Informative)

    by messju ( 32126 ) on Tuesday April 10, 2018 @10:30AM (#56412429)

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

    • It's not pre - installed on Mint either

      • Nor on Ubuntu. I can't imagine anybody going out and just getting this package. Is there anything that gets it as a pre-req?

    • Re: (Score:3)

      by sjwest ( 948274 )

      Its not debian installed by default

      beep does what you'd expect: it beeps. But unlike printf "\a" beep allows
      you to control pitch, duration, and repetitions. Its job is to live inside
      shell/perl scripts and allow more granularity than one has otherwise. It is
      controlled completely through command

      I suppose somebody needs that, not us.

    • Re: (Score:2)

      by tomxor ( 2379126 )
      Yup, I just tried it.

  • So (Score:3)

    by Greyfox ( 87712 ) on Tuesday April 10, 2018 @10:53AM (#56412575) Homepage Journal
    Another setuid vulnerability in this day and age? You'd think it was difficult to find all the setuid programs on a system and audit the shit out of each and every one of them.

  • The real pun to this vulnerability is the fact it is a race condition in the "beep" package [thelicenseplatesite.com].

    Beep! Beep!

  • I find it ironic... (Score:5, Insightful)

    by frank_adrian314159 ( 469671 ) on Tuesday April 10, 2018 @10:57AM (#56412605) Homepage

    ... that a command that probably started life as putchar('\007'); could morph into some monster needing to spawn threads and have race conditions.

    • The command is a bit more complicated than that. It allows you to specify the tone and duration. And the race condition comes because (a) multiple processes can call it simultaneously and (b) there is signal handling code present so that the speaker isn't left beeping in perpetuity should the process somehow get killed in the middle of a beep! If you look at the proposed patch, things make a bit more sense. And the FAQ is hysterical https://holeybeep.ninja/ [holeybeep.ninja]

  • The one thing that's been driving me nuts since switching to Debian testing (from Fedora) is X using system beeps to alert, even though Pulse is running. I'll have to see if something dragged in 'beep' as a dependency when I get home.

    • Re: (Score:1)

      by Anonymous Coward

      rmmod pcspkr

  • FFS (Score:1)

    by Anonymous Coward

    Is this really where we are now? How many decades of computer science and security research and there's a vulnerability in beep?

    Pack it up. We're done. Computers were good while they lasted, but maybe our pending cockroach overlords will get this whole computer thing straightened out better than we did.

  • So, when the attacker do this, does it now beep or not?

    • Re: (Score:3, Funny)

      by Anonymous Coward

      no they would use beep --silent

  • Now you can beep your way to success.

  • According to the FAQ, beep has to be installed as setuid root for this to work.
    Why the heck would beep need root? I'm guessing in order to access the hardware, but that's what we are supposed to have HALs for?

  • From their website:

    "How many people are affected?
    Millions! Everyone, almost.
    According to the Debian popularity contest, beep is installed on 1.86% of all machines. Extrapolating that by the earth population, we estimate roughly 130 million affected users."

    130 millions is probably an order of magnitude bigger than all debian users. That extrapolation is ridiculous. Is this supposed to be a tongue in cheek number?

Slashdot Top Deals

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Close