Two voice platforms from unrelated vendors were written up within days of each other, and both ended at root the same way. Not through a clever memory bug or a novel protocol trick. Through one line in a sudoers file letting the web server user run an ordinary utility as root without a password.
That line is probably on your box too. It takes about twenty minutes to find out.
The pattern, before the details
Different vendors, different code, identical last step.
Every chain of this shape has three links. Reach the admin area without logging in. Get a command to run as whichever user the web server runs as. Then turn that unprivileged shell into a root shell.
The first two links are ordinary web bugs and they get all the attention. The third is the one that decides how bad your day is, and it is the one you can fix yourself without waiting for anybody.
The case with CVEs attached
Telenia TVox is a contact centre and PBX platform. Three issues were published against it, and they line up with the three links exactly.
The bypass works because a script decides which page you asked for by reading PHP_SELF. Append a login filename to the path of any admin script and the check reads the appended name, decides you asked for the login page, and lets the request through. Rated 9.8, and you can see why.
The injection is a process id taken from a request and passed into a shell call without sanitising. Feed it something that is not a process id and you get a command.
The escalation is a file the installer drops into the sudoers drop-in directory. It lets the web user run nice as root with no password. That affects 26.5.3 and earlier in the 26.x line, and 24.9.21 and earlier in the 24.x line.
The case without them
A researcher published a similar chain against Cisco Unified Communications Manager 15.x under the name Silent;Call. Treat this one differently: no CVE has been assigned, and there has been no vendor response. It is a claim, not a confirmed advisory.
Read as a claim it is still useful, because the shape is the same. The bypass is a server trusting an X-Forwarded-For header from anyone, so a remote request can present itself as coming from localhost and walk past checks written for local traffic. The access is management credentials the researcher says are identical on every install. The escalation is a sudoers file permitting gdb as root with no password.
Whether that specific report holds up matters less than the fact that you can check both of those conditions on your own systems in a few minutes, and neither check requires anyone to confirm anything.
Why nice and gdb
Neither of those is a security tool. That is exactly the point.
A sudo rule that permits one specific binary feels tight. It reads like a narrow grant. The question that actually decides whether it is narrow is different: can that binary start another program?
nice exists to run a command at an adjusted priority, so running a command is its entire purpose. gdb can execute shell commands from inside a debugging session. Give either one password-free root and you have not granted a capability, you have granted a shell.
The same is true of editors that can shell out, archivers with a filter option, schedulers, package tools, interpreters and a long list of others. The public GTFOBins project catalogues them, and it is worth assuming an attacker checks it before you do.
So the rule to apply is not “is this binary dangerous”, because nice is not dangerous. It is “can this binary start another program”, and for a surprising share of the utilities that end up in sudoers files, the answer is yes.
Why voice platforms collect these rules
This pattern shows up in telephony more than in most software categories, and there is a reason that has nothing to do with carelessness.
A voice platform genuinely does need privileged operations from a web interface. Reloading a dialplan, restarting a channel driver, binding low ports, reading call recordings owned by another user, adjusting the priority of a media process so audio does not stutter under load. Every one of those is a real requirement, and the quickest way to satisfy it during development is a sudoers entry.
The entry gets written to unblock a feature and it ships. Nobody revisits it, because it is not a feature and it has no owner. Years later it is the last link in somebody’s chain.
Auditability is where open source has a genuine edge here, and it is worth being precise about what the edge is. Open source does not mean fewer bad sudo rules. It means you can read them, and you can change them without asking permission. When you run the platform yourself you can open the drop-in directory, see exactly what the installer granted, and narrow it. On a closed appliance you get whatever the vendor decided, you often cannot see it at all, and you wait. If you are weighing up open source VoIP software for a deployment, that difference is more practical than most of the arguments usually made for it.
What to check this week
None of this needs a vendor advisory or a maintenance window.
Start with the sudoers rules, and read the drop-in directory as well as the main file. Vendors install their own file under /etc/sudoers.d/ and it will not appear if you only open /etc/sudoers. Any line containing NOPASSWD should have a reason you can say out loud.
For each one, ask the spawn question rather than the danger question. If the permitted binary can start another program, that rule is equivalent to full root for whoever can reach it.
Then check how your stack decides that a request is local. If anything reads X-Forwarded-For to make a trust decision, restrict it to the addresses of your own proxies. Left open, a remote caller can claim to be 127.0.0.1 and pass checks that were written on the assumption that localhost meant somebody already inside.
Put the admin interface behind a VPN or a source-address rule before you patch anything. Most of these chains start at a web management port, and removing the entry point protects you against the bugs nobody has written up yet, which is a category you cannot patch by definition.
Finally, rotate anything that shipped with the software. Management consoles, database users, service accounts. If a credential arrived in the install, treat it as public and make rotating it part of the install rather than a task for later.
The part that is actually hard
None of those five checks is difficult. Doing them on every box is.
Most operators do not have one voice platform. They have a PBX, a recording server, a provisioning box, a billing system and two things somebody set up in 2019 that still answer on port 443. The sudoers rule you need to find is on the one nobody remembers.
So the useful output of this exercise is not a clean sudoers file. It is a list of every machine in your estate that runs a web interface as a service user, with a name next to each. That list is worth more than the individual fixes, because next time something like this is published you will know in an afternoon whether it applies to you, instead of finding out later.
If you are building or consolidating that estate, the design decision worth making early is which components you can actually inspect. Our own notes on building VoIP infrastructure with open source tools go into how the pieces fit together, and the monitoring side covers keeping visibility once it is running.
Frequently asked questions
What is a passwordless sudo rule and why is it risky?
It is a line in a sudoers file permitting a specific user to run a specific command as root without being prompted for a password. The risk is not the missing password, it is the command. If that command can start another program, anyone who can act as that user gets a root shell.
How do I find sudo rules a vendor installed?
Look in the drop-in directory as well as the main sudoers file. Installers commonly place their own file under /etc/sudoers.d/, and it will not show up if you only read /etc/sudoers. Read every file there and treat each NOPASSWD line as needing a justification.
Is nice really dangerous?
On its own, no. Its purpose is to run a command at a different priority, which means running a command is what it does. Granted password-free root, that purpose becomes a way to run any command as root. The same applies to debuggers, editors that can shell out, archivers and schedulers.
What does X-Forwarded-For have to do with authentication?
Some applications treat requests from localhost as trusted. If the application reads the forwarded-for header to work out the client address and accepts it from anyone, a remote attacker can set it to 127.0.0.1 and inherit that trust. Only accept the header from your own proxy addresses.
Should I act on a vulnerability report with no CVE?
Act on the underlying conditions rather than the report. You cannot verify somebody else’s claim, but you can check your own systems for default credentials, spoofable forwarded-for handling and passwordless sudo entries. Those checks are worth doing whether or not the specific report is accurate.
Does open source make a VoIP platform more secure?
Not automatically. It makes the platform inspectable, which is different. You can read the sudoers file the installer dropped, see what the web interface runs as, and change either one without waiting for a vendor. The security comes from doing that, not from the licence.
Related resources
- Open Source VoIP Software: Top IP Telephony Applications
- Building a Scalable VoIP Infrastructure with Open Source Tools
- Open Source Tools for VoIP Quality Monitoring and Troubleshooting
- Comparative Analysis of Various Open Source SIP Servers
- Introduction to VoIP: Learn the Fundamentals
Where to go next
If you ran the five checks and found a rule you cannot explain, the next question is usually whether the platform needs it at all. We build and support open source voice infrastructure where the answer to that is something you can change rather than something you have to accept. Tell us what you are running and we will help you work out which of those rules is load bearing. Open a ticket at service.ictinnovations.com.