31–40 of 103 posts
Earlier quoted context omitted.
> 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?
How would the compiler know that a function was a signal handler?
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 :)
And that virtio-beep existed.
I wonder what would happen if I pushed to get the support into KVM and the kernel. Best case scenario, the videos accompanying the too-bemused-to-really-be-angry bug reports would be legendary.
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://gi…
Heh
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.
#include
main() { beep(); }
Earlier quoted context omitted.
It wouldn't. But it might be possible to make it impossible to call forbidden_function() from anywhere where it shouldn't be possible. For example: the signal handler would be a function that accepts an argument of some kind, and the argument is the key to reaching all apis allowed from that point (e.g. the argument must be passed on to allowed apis, or the argument contains function pointers to all allowed functions…
How would you differentiate a function that takes an argument of some kind and handles signals from one that just takes an argument of that kind (e.g. for debugging, logging, or some other sort of introspection)? Edit: to be clear -- I'm not asking this just to be snarky :-). Inferring functional information from nothing but semantic information with no functional implication is a very complicated problem that has ve…
Earlier quoted context omitted.
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
I don't see the need to qualify "curl | sudo bash" with it being a two line script for it to be problematical. "curl | bash" or "curl | sudo bash" is problematical no matter how large or small the script. Yes, I know some people say that it is no worse than downloading to a file and then running the file without reading the script, which is what almost everyone does anyway. These people are wrong. Downloading to a fi…
why not just detect the `curl | bash` part server-side?
I'm still amazed how many FOSS projects have that as the primary installation path...
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...
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?
I find this very useful, a lot more useful than to say "If you don't even read the manpages there is no help in sight".
Maybe the compiler should not do it but perhaps you could run a linter against packages that are shipped with an os to find issues like this easier.
Earlier quoted context omitted.
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.