Bug 1595591 (CVE-2018-1000532)

Created beep tracking bugs for this issue:

Affects: fedora-all [bug 1595592]

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.

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
root.

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.

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.

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.