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.
Beep security update
11–20 of 103 posts
Re: Beep security update
#12Earlier 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
> 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
#13Also see https://holeybeep.ninja/
* curl | sudo bash for two lines of script
* said script just checks if you have beep installed, not if you're vulnerable
Re: Beep security update
#14Also 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
Re: Beep security update
#15[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2...
Re: Beep security update
#16Also 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
#!/bin/sh
# TODO: Backdoor this machine?
modprobe pcspkr
beep -l 1000 -r 3 -f 44000Re: Beep security update
#17Also 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
> No.
> How do I uninstall Linux?
> Please follow instructions.
Shirley it's not meant as a serious resource.
Re: Beep security update
#18By 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.
Re: Beep security update
#19The 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...
Why is it accepted by the compiler, then?
Re: Beep security update
#20The 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?