Linux Beep bug joke backfires as branded fix falls short Retro programmers may need to reconsider using the Linux beep command as an activity or progress alert. One of the silliest bugs on record emerged late last week, when Debian project leader Chris Lamb took to the distro's security to post an advisory that the little utility had a local privilege escalation vulnerability. The …
Amusingly, the man entry for beep contains this wonderful little passage.
"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."
Ah, hindsight.
According to Debian, only 1.88% of users have beep installed. Only 0.31% use it regularly. Apparently "beep" doesn't even work on most hardware. I suspect that the few people who do have it installed used it in a bash script somewhere years ago and forgot it. I checked my PC (Ubuntu), and It is not installed.
The best solution is probably to check if you have it installed, and if you are one of the few people to who, to simply un-install it. If you are worried about some obscure script failing because it got an error when it tried to call beep, then perhaps symlink some fairly innocuous "do nothing" command, or possibly even a script which will write to a log somewhere to tell you when it was called.
If I need to have my speakers on my desktop make any noise I use "espeak", which is a text to speech utility. There are other noise making utilities as well which unlike beep actually work on modern hardware.
"How do they know this? Does Debian slurp collect telemetry?"
Upon installing debian you are given the option to opt-in to the package popularity survey which reports back to them what packages you have installed so they can determine which packages are the most popular. They use this to put the most commonly wanted packages on the first/second DVD images so simply downloading the first DVD should get you the most popular packages straight away.
I guess the survey also records how often the package is actually used.
I always opt in; accurate statistics are important, as cases like this illustrate. And hey, if that means Debian bases packaging decisions based only on people like me, I can love with that ;)
(More serious answer: statistically speaking, even a very small percentage of Debian users opting into popcon is probably nonetheless quite statistically significant of a sample size, so I bet their numbers are fairly accurate.)
" ... only 1.88% of users have beep installed. Only 0.31% use it regularly "
That's a very good example of the reason you shouldn't apt-get dist-upgrade forever (or your package management distribution upgrade of choice equivalent). This process leaves obsolete packages installed which you probably no longer want and which seem destined to come back and bite you when you least expect it. Doing a full and clean install occasionally, apart from maintaining knowledge of how to configure stuff you've become dependent upon, will keep a system in a more sane condition.
Totally agree with you; trick is that with production systems a lot of people cannot frequently rebuild as I would, say, my home Linux and windows boxes.
I do spend a fair amount of time looking over the installed package lists on production boxes and asking, "what is this one... and this one... Do we really use every version of python since the beginning of time or is cruft accumulating?" And so forth. I actually schedule days for in-depth consideration of open ports, services exposed, etc. Sometimes the need for something passes and you get an opportunity to reduce your attack surface.
I'm sure this tool exists and I'm too dumb to know what it is, but if not here is my proposal: develop a script that crawls around and looks at last access times on files and associates these with installed packages... If all files associated with a package haven't been accessed in <defined> months, inform admin that maybe the package is unnecessary?
You only can't rebuild production systems from cold if you either don't have enough redundancy, or you don't have any reliable way of reconstructing the things that live on the system from cold.
Both of those things are often true of course, sadly.
apt-get doesn't remove obsolete packages because you may be using software from outside of the official repos that depend upon them and for which there may be no later releases or alternatives.
A 'full and clean install occasionally' (when, and on what basis?) is a non-starter if you're doing work on a system and is a very poor way to maintain a system - there is a choice of package managers and utilities that will flag obsolete packages, identify orphaned (unused) dependencies and allow you to selectively remove them.
I the last full clean install I've done was more than ten years ago - new systems get cloned and then modified as needed. Cloning on Linux is relatively quick and easy using standard utils and fwiw I install multiple clones, each in their own small partition, on each system so if a problem, for what ever reason, occurs on the 'running' or currently booted system I have a number of fall-back systems I can boot. Personally, I tend to rotate them as major upgrades occur, so I preserve the last good known working version and perform the upgrade on a new clone in its own partition.
"Doing a full and clean install occasionally"
Why would you want to do this? It's highly disruptive and gains you nothing. I would, instead, recommend just going through your installed packages every so often and removing the ones you no longer need.
"According to Debian, only 1.88% of users have beep installed. Only 0.31% use it regularly."
I have beep installed, and use it regularly, but there's no way that Debian could know that -- so I'm not reflected in those stats. I expect that most people who use beep are developers of a certain type, and that type is precisely the sort that does not allow telemetry.
So, while I have no problem believing that a very small minority of Debian users have and use beep, I would be very surprised if the numbers were as low as Debian is reporting.
Every system of mine still has one of those little "PC Speakers" - They almost always come with the motherboard. When I'm building the systems I put them in because, well just because.
They can also be useful in the event of hardware failure as sometimes a motherboard can beep the problem to you[1] - I've fixed a few machines using beep codes for diagnostics.
So I wouldn't call those little speakers useless. For the most part if you don't want your OS beeping at you, you can simply not load the pcspkr kernel module[2] and it won't function from the OS thus leaving it for bootup checks only.
I'm guessing these days when everyone is putting all their PC/Server components together they don't bother putting those little speakers in? Well, that's fine but I still do... maybe I'm just old :-D.
[1] For example: https://www.computerhope.com/beep.htm (First duckduckgo result)
[2] Most of the time when the "beep" command does not work it is because this module is not loaded
They can also be useful in the event of hardware failure as sometimes a motherboard can beep the problem to you[1] - I've fixed a few machines using beep codes for diagnostics.
I've done this twice. The last time was a machine with a tendency to overheat, and it would beep out "CPU not running" when it rebooted. Cleaning the heatsink and fans resolved that one.
The other was about twenty years ago, when I flashed the BIOS on a machine and the process evidently failed. It rebooted and beep beep beep... with the black screen of nothing. I read the manual, and found out why, and how to fix it.
I got a blank floppy and downloaded the new BIOS onto it (using a different machine, duh). Then I put the floppy in the paperweight's A: drive, powered it up and waited. Beepty beep, drive seeking clunk clunk clunk ... Beep. Reboot. Machine alive.
Ever since that day I have been leery of upgrading the BIOS...
"Ever since that day I have been leery of upgrading the BIOS..."
You really shouldn't be. I've replaced 1000's of motherboards over the years and a BIOS update is pretty much the first step after powering up and never had a failure. BIOS upgrade failures are incredibly rare and most often caused by another underlying fault, dirty power or using an incorrect firmware file in error. My experience covers desktops, servers and laptops of various brands too, so anyone concerned by the "scare" stories really shouldn't be. Just be careful to use the correct tools and firmware versions.
Every system of mine still has one of those little "PC Speakers" - They almost always come with the motherboard. When I'm building the systems I put them in because, well just because.
Exactly. Every MoBo I've ever come across has a jumper for a speaker, and they are a godsend for diagnosing boot-time issues such as poorly seated components.
If you have children, they're also useful for letting you know when small fingers have pressed the power button when you're in another room.
Agreed, my latest AMD Ryzen motherboard from ASUS came with the standard front panel header, which includes the speaker pins, and a speaker.
However those little speakers that you just plug into the board and leave hanging are annoyingly quiet sometimes!
Without a PC beep upon boot I automaticaly wonder if there is something wrong. A successful POST must beep at you even if its via the on-board audio.
Also I frequently use the beep program withing my commandlines.
"They can also be useful in the event of hardware failure as sometimes a motherboard can beep the problem to you"
Most motherboards also have an LED 7-segment display that gives boot and error information in a much more readable format though. Trying to figure out a pattern of beeps is a lot more difficult than just reading an error number. Unless the fault you're trying to diagnose turns out to be that the LEDs aren't working, there's really little use for the speaker.
"I must be buying really oddball computers, then (not unlikely), because not one of the ones I own has such a display."
Ditto. We supply three major brands of motherboard as well as a couple of major brand desktop systems and at most there may be one, possibly two status LEDs on the motherboard (or none at all)
Cuddles wrote:
Most motherboards also have an LED 7-segment display that gives boot and error information in a much more readable format though.
Huh? Not come across a motherboard with one of those yet. Generally I'm dealing with SuperMicro, Asus, AsRock (basically, Asus again) and Gigabyte.
Would be interested to see one of those though :-).
Supermicro C7Z170-SQ has one of those 7-segment displays onboard.
I ran into a weird issue where boot took about 45 minutes. At least I could see something was going on. After a bios update it was fine again.
Either way, not buying something from that range again. Stupid graphical bios.
"They can also be useful in the event of hardware failure as sometimes a motherboard can beep the problem to you[1] - I've fixed a few machines using beep codes for diagnostics."
Most laptops I've worked on in recent years will do a beep code or equivalent power LED flash code, but most desktops nowadays only ever seem to have a single beep code of "failed to complete POST". Most often it's a catastrophic RAM failure. If they even beep at all. Probably because for most users purposes, it doesn't matter what the failure is if POST fails before the video is initialised. It's the same bit you need to replace, ie the whole motherboard. Multiple beep codes indicating failed ports/controllers when most I/O were separate add-on cards made sense.
"In my opinion, this is one of the least important security problems ever."
Me too , which is why it makes me sad that so much effort has been put into that HoleyBeep web page... Just leave the distros (that include it) to patch it in their own time, I can't imagine any automated scripts are using 'beep' rather than 'mail'.
Well I wouldnt be surprised its not installed because nothing generally depends on the beep package so it wont get installed. The only stuff installed are the selected packages and their dependancies and beep is unlikley to be useful by itself unless you need it whihc is when you end up installing it.
Packages that I also dont expect to auto-install include OpenSSH server, Midnight Commander, mutt, emacs (default install for most distros is nano) etc etc. Of course I manually install those first thing as I must have them ;)
The difference is that the security implications were detailed in the man pages and you can fix this yourself very easily whereas with Windows you would have wait for Microsoft to provide a fix if a) they found the issue in the first place and b) they actually decide to fix it rather than logging as "won't fix".
The difference is that the security implications were detailed in the man pages and you can fix this yourself very easily whereas with Windows you would have wait for Microsoft to provide a fix if a) they found the issue in the first place and b) they actually decide to fix it rather than logging as "won't fix".
That's no different to Linux though. The average user (I.e., pretty much everyone if Linux were to ever become more than a fringe OS) wouldn't ready the man pages, certainly wouldn't know how to fix it themselves, and would have to wait for their distro provider to ship an update.
In fact that very attitude of "you can fix this yourself" very nicely illustrates exactly why Linux never will gain widespread adoption on the desktop.
"The average user (I.e., pretty much everyone if Linux were to ever become more than a fringe OS) wouldn't ready the man pages, certainly wouldn't know how to fix it themselves, and would have to wait for their distro provider to ship an update."
True. But that sort of user would never have installed beep to begin with, so it doesn't matter.
But that sort of user would never have installed beep to begin with, so it doesn't matter.
Well, that sort of user would most probably be at the mercy of their distro provider to install software that they would deem "necessary" for the smooth operation of the OS. While this might be a relatively unlikely/benign utility, it wouldn't take too long for something more necessary to be exploited. Most probably in the form of an unpatched/out of date library.
I am not aware of any distro that installs beep as part of a standard installation. It would be weird if one did, as the utility is not useful except for fairly specialized situations, and distros tend to avoid automatically installing anything that isn't useful to a wide range of users.
@Anonymous Coward said: "It's not on Windows."
Oh look, someone trolling anonymously. What a surprise.
Well guess what, it's not normally installed on Linux either, as you would know if you had actually read the story. It's a third party program that an administrator can install if he or she wants to, but very, very , few actually do.
... send ^G to the terminal? New one on me. I guess somebody thought it'd be useful. But who? And when? And more to the point, why?
Then again, curses has the ability to beep and flash. man curs_beep
If your terminal supports it, that is. At a shell prompt, try echo ^G to see if your terminal will beep. Might have to escape the ^G with ^V ... Do they even teach this stuff to newbies anymore?
Just tried
echo "\007"
.... and the front doorbell rang! Coincidence ... I think not.
(N.b. ever since I realized that "^G" was octal 007 I've been hopiong for James Bond film where he encounters an elderly programmer who looks up ands say "ah, James Bond 007 ... that's a name tro used to ring a bell")
Yeah except if you want echo to interpret backslash escape sequences you need to use the -e option (at least on all my Linux machines) so the command needs to be echo -e "\007" though echo -e "\07" works, as does echo -e \\07 which is a even fewer characters. However instead of using random octal why not use \a which is the alert backslash sequence so echo -e \\a is the shortest variant.
Well I believe it provides the ability to change the and duration. Something that I used to great effect at college, writing a little app that played a little tune, then proceeded to warble out a sort of siren, slowly rising and falling in pitch. (This was on windows though, not using the beep app here).
Somehow, I managed to make it (purely by accident) continue running even after the user logged off unless they killed it first.
Probably inevitably, having shared it with a friend, it ended up daisy-chaining around the college.
IT ended up going round all of the computer rooms (and this was a big college) disconnecting all the internal speakers from each and every machine, all thanks to me. Whoops.
"I guess somebody thought it'd be useful. But who? And when? And more to the point, why?"
I would guess for daemon programs that don't have a controlling terminal but want to audibly signal that there's a serious problem to the operator (for back in the day when someone would actually be sitting in the machine room).
"One could ask the same of the vast majority of software packages and features, and never receive a satisfactory answer,"
It depends who you ask. Ask most people who thought, say QGIS (what's that, you've never heard of it?) was for and you'd receive blank looks. But there are enough people who need a GIS (never heard of that either?) to develop it originally and to continue with that.
"I guess somebody thought it'd be useful. But who? And when? And more to the point, why?"
If you're doing low-level programming, the ability to beep can be incredibly useful. When something goes wrong or you are debugging and the system isn't in a state where you can do high-level I/O, or the code you're working with is at a level where high-level I/O is difficult to do, beeping the speaker is an easy way to get status and debugging information.
It's less useful if you have to go through the terminal to do it, though. Better to have code that just beeps all by itself.
I used to use it all the time (I know the jonath domain by heart).
It was a great tool for PC systems that weren't full desktops for everything from identifying machines to indicating problems via a series of tones. Not always was a ^G able to be sent, or sufficient, for such purposes. It's much easier to break out to shell and run a specific program, if for no other reason than echoing scripts that do the same will also beep even though you're only viewing the script, not to mention what's the controlling terminal nowadays with everything from virtual terminals to SSH, containers to virtual machines, etc. - where does the ^G actually play the sound? Beep played out of the hardware of the physical machine you were executing on (hence why it liked to have root).
For instance, a home machine that controlled the Internet connection has no screen or speakers except the internal speaker and used to have a set of rising or falling tones if the Internet came up or went down. I literally never had a graphics card in that machine, so it was very handy, and just a ^G is insufficient to convey that.
However, to tell you how long ago that was, it was a 386 running Freesco on a 2.0.38 kernel, and the Internet was a modem connection which I used to have to turn-off to let my dad make a phone call and it was useful to know that the modem was stopped from dialling out (the falling tones) and when it had managed to restart the PPP session after resuming (the rising tones). If you kept hearing both, it was still trying to dial out.
I know that a lot of embedded hardware still has the same kind of things in them - everything from firewalls to NVR servers - to let you know when they've completed booting. Not to mention that I don't think I've ever owned a computer that WOULDN'T output the sound from beep if you installed it. It might be a PC speaker passthrough header on a sound-card or motherboard, but it usually still works, I believe.
That said, it's probably a long-abandoned bit of software given that it's been 20 years since then, and all it does it beep, and that's pretty much everything you wanted it to do even 20 years ago. It should have been audited, it should have been caught, and being setuid (or suggesting so), it should have been subject to a higher level of scrutiny.
I bet there are a million machines out there with it on, just for those rising-tone power-up notifications in embedded devices, if they're not using some busybox equivalent.
Some of these DOS devices can't be used as filenames on Win10
AUX 1st serial port
PRN 1st parallel port
COM1 thru COM4 Serial ports (NT had /has Com1 to Com255, TTY is UNIX/Linux equivalent)
LPT1 thru LPT3 Parallel ports (Don't know how many NT had)
CON Keyboard and screen
NUL Dummy (for testing)
Wasn't there also a punch and reader device in early DOS? (names?) or was that CP/M?
While it's dead now, the COM executable format in MS-DOS existed to make porting CP/M software easier, and persisted well into the Windows era.
Some vestigial chunks of the IBM XT BIOS persisted into the 90s; I remember accidentally powering up an early 386 with no disks attached, and seeing "NO ROM BASIC" in glorious 40-column text.
Read this the other day - rather interesting on the history of the PC beep and why it survived for so long after the advent of the soundcard (spoiler: disability legislation).
the POST beeps are (were) one of the most useful basic diagnostic tools where there's no video or other diagnostics on the motherboard.
Turn on the big red switch.
Wait.
Listen.
One short beep and you're good. Unless you have a COMPAQ clone rather than a genuine IBM PC so you get 2 beeps and think something is wrong until you quickly remember!
I recall many years ago when someone (ESR?) published a sound driver (maybe for ALSA?) to allow one to use the PC speaker as a generic audio output device, so you could, for example, play your pirated Duran Duran mp3s _anywhere_ (until the sound stack broke again).
Compare and contrast to my memory of setting up racks of headless servers where ticking the "Server" install config would load up an impressive collection of audio and video drivers, in case I wanted to watch a movie on the non-existent monitor with 5.1 sound via the non-existent sound card.
Would it run on WfW? I still have a few licensed copies on (formerly) sealed floppies. Raises the question of whether the "Breaking this seal..." contract would apply, as the glue sealing the envelopes rotted away some years ago.
Anyway, if someone has a set of samples to mimic Votrax. we could combine them with your speaker driver and a text-to-Votrax driver I have around here somewhere. Isn't Science Wonderful?
Yes, the Win 3.x speaker sound driver (that was on a cover disk once) does work on WFW3.11. It's possible it works on Win9x as those are basically Win3.x with updated Win32s, updated version of VFW, added Direct X (to allow porting DOS games) and the Win 3.x 32bit disk & network stack all "included". Replacing Progman.exe and winfile.exe with explorer.exe. It was sad that it was so popular and held back NT development and adoption, and ultimately saw programs with broken security on NT that needed you to be the Administrator. The Win9x development and inept win9x programs were responsible for most of the ills of NT 4.0 and NT5.x (Win2K, XP, Server 2003). After 2003 it's been downhill all the way.
The phrase "until the sound stack broke again" made me chuckle, because I don't think I've had reliable sound in Linux since they abandoned OSS for ALSA. I recently replaced my Ubuntu media PC setup with Windows 10 because one too many evenings where I wanted to watch a movie ended with me trying to figure out why ALSA's HDMI sound output mysteriously stopped working again.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
