Live data from Hacker News

Beep security update

debian.org

11–20 of 103 posts

Re: Beep security update

#11
post #2

Can't one just sudo echo -e "\7” anyway? Or if you're trying to do something fancier there is snd-pcsp which lets use use the piezo as a normal ALSA device (quality may vary). Not that many modern machines even include such a useful device.

If you're connected to a remote server, `echo` will annoy you and your cat, but `beep` will annoy the server administrator :)

Re: Beep security update

#12
post #10

Earlier quoted context omitted.

Why would that need root? Is it not up to your terminal emulator to interpret the \7 and trigger the actual beep?

See the "A note about ioctl" section of the README: https://github.com/johnath/beep

That section says:

> there's only one file opening, and while there is a potential race condition there, it's with /dev/console. If someone can exploit this race by replacing /dev/console, you've got bigger problems. :)

However, by reading the source one can see that you can now tell beep where it should direct its output (-e, which is not documented anywhere), so the note above is no longer accurate.

I would guess that this is the crux of the problem – the patch that fixes the security issue basically changes "open the output device once for each beep" to "open the output device on startup", greatly reducing the number of races. (It also zeroes out the buffer that's being written to certain output devices, but I have no idea if that is also to patch this security hole or to proactively prevent uninitialized bytes from leaking.)

Re: Beep security update

#14

Also see https://holeybeep.ninja/

I've got a couple of problems with that page: * curl | sudo bash for two lines of script * said script just checks if you have beep installed, not if you're vulnerable

Given the sardonic and amusing way the rest of the page is written, my guess is that's a part of the joke.

Re: Beep security update

#16

Also see https://holeybeep.ninja/

I've got a couple of problems with that page: * curl | sudo bash for two lines of script * said script just checks if you have beep installed, not if you're vulnerable

Not sure if you're aware of that but it's a joke page made as a parody of the recent "branded vulnerability" craze. I would definitely advise against running random scripts from joke pages, especially through sudo. In that regard notice the "TODO" line from the script:

    #!/bin/sh
    # TODO: Backdoor this machine?
    modprobe pcspkr
    beep -l 1000 -r 3 -f 44000

Re: Beep security update

#17

Also see https://holeybeep.ninja/

I've got a couple of problems with that page: * curl | sudo bash for two lines of script * said script just checks if you have beep installed, not if you're vulnerable

> Is this an OpenSSL bug?

> No.

> How do I uninstall Linux?

> Please follow instructions.

Shirley it's not meant as a serious resource.

Re: Beep security update

#18
From the beep readme:

By default beep is not installed with the suid bit set, because that would just be zany. On the other hand, if you do make it suid root, all your problems with beep bailing on ioctl calls will magically vanish, which is pleasant, and the only reason not to is that any suid program is a potential security hole. Conveniently, beep is very short, so auditing it is pretty straightforward.

https://github.com/johnath/beep

Re: Beep security update

#19

The author of beep needs to read the POSIX specification on async-signal-safety [1]. In particular, it is not safe to call exit, free, ioctl, putchar, or perror from a signal handler. [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2...

> In particular, it is not safe to call exit, free, ioctl, putchar, or perror from a signal handler.

Why is it accepted by the compiler, then?

Re: Beep security update

#20
post #19

The author of beep needs to read the POSIX specification on async-signal-safety [1]. In particular, it is not safe to call exit, free, ioctl, putchar, or perror from a signal handler. [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2...

> In particular, it is not safe to call exit, free, ioctl, putchar, or perror from a signal handler. Why is it accepted by the compiler, then?

Why wouldn't it be? Why would a compiler know what a signal handler is?
Post reply on HN