Bug 1595591 (CVE-2018-1000532) - CVE-2018-1000532 beep: External control of file name or path via --device option
Summary: CVE-2018-1000532 beep: External control of file name or path via --device option
Alias: CVE-2018-1000532
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1595592
TreeView+ depends on / blocked
Reported: 2018-06-27 08:05 UTC by Andrej Nemec
Modified: 2019-09-29 14:43 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-06-10 10:30:42 UTC

Attachments (Terms of Use)

Description Andrej Nemec 2018-06-27 08:05:54 UTC
beep version 1.3 and up contains a External Control of File Name or Path vulnerability in --device option that can allow a local unprivileged user to inhibit execution of arbitrary programs by other users, allowing DoS.



Comment 1 Andrej Nemec 2018-06-27 08:06:18 UTC
Created beep tracking bugs for this issue:

Affects: fedora-all [bug 1595592]

Comment 2 Hans Ulrich Niedermann 2018-12-28 14:40:12 UTC
Summary on the impact of CVE-2018-1000532:

As Fedora ships the beep package, the beep executable never changes priviledges
(via setuid or sudo). So out of the box, CVE-2018-1000532 has no effect on Fedora
users of the `beep` package.

However, Fedora users must explictly reconfigure their system for `beep` to
actually beep the speaker, as the `pcspkr.ko` module is not loaded on Fedora by
default). And while they were at it, they might as well have set up `sudo` to
provide priviledges for `beep`. The Fedora `beep` package even suggests that
kind of setup in the commented out example configuration it ships in the file
`/etc/sudoers.d/beep` and the text in `README.fedora`.

I have no idea how many Fedora users might actually have set up `beep` to
gain priviledges through `sudo`.

Some people may have even set the `beep` executable setuid root. We neither
suggest or mention setuid root. `beep` does not refuse to run if
`(geteuid() != getuid())` either, though. I have no idea how many people might
be affected here.

I am not aware of other ways `beep` could be set up to gain priviledges than
`sudo` or setuid root, so this concludes my summary on the impact of
CVE-2018-1000532 on Fedora users.

Comment 3 Hans Ulrich Niedermann 2018-12-29 05:25:47 UTC
Unfortunately, upstream's `README` and upstream's `beep.1` man page both
suggest making `/usr/bin/beep` setuid-root. The Fedora package ships both
files. This might have increased the number of people running beep setuid

However, a simple package update should overwrite the /usr/bin/beep
executable with mode 0755, i.e. without the setuid bit set, and also the
new /usr/bin/beep will not do anything if running setuid root or from sudo,
so the new update should close the hole for those people as well.

Comment 4 Hans Ulrich Niedermann 2019-01-10 12:22:03 UTC
I forgot to explain how the new beep packages fix the issue. So here comes that explanation.

Old beep (before the beep-1.3-26.fc* packages) used the KIOCSOUND API, which
works on devices like /dev/tty[0-9]+. For that API, the kernel insists that
you are either root, or own the TTY. That caused the setuid and sudo based
methods to be used.

The kernel people have probably notice that issue many years ago and introduced
a better API: The evdev input device API. This uses the well-known device name
/dev/input/by-path/platform-pcspkr-event-spkr which is a symlink to an input event
device like e.g. /dev/input/event42. The system administrator can use normal file
permissions to allow write access to /dev/input/by-path/platform-pcspkr-event-spkr
which allows us to avoid the whole issue of being root.

Unfortunately, old beep did not try /dev/input/by-path/platform-pcspkr-event-spkr
by default - you had to explicitly give the device name on the command line!

New beep tries /dev/input/by-path/platform-pcspkr-event-spkr first. The new beep
packages (beep-1.3-26.fc* and later) set up a "beep" group and allow group write
access for members of the beep group. This means being root is not required any
more for running beep.

Also, new beep aborts before doing anything if it detects being run setuid or
via sudo, so even if there are remaining sudo configurations, or someone makes
beep setuid-root by habit, beep will not do anything any more in those cases.

Comment 5 Product Security DevOps Team 2019-06-10 10:30:42 UTC
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.

Note You need to log in before you can comment on or make changes to this bug.