I was right. Using system() in a program is a bad idea, especially if you pass parameters that the user can enter. Now with the latest internet security meltdown called shellshock it is official.

To put this right up front, for the Vodia PBX program itself the damage is zero. It simply does not fork a shell.

[For those who have the time to disassemble the PBX code. There is still a system call from old version 4 times, but we are not referencing that function in version 5 anymore. Time to completely take it out.]

Other architectures might have a different experience this weekend. It is not usual to use popular CGI-based web servers to integrate the HTTP world with the SIP world. Because of the architecture, there is often no other way to tell other processes to perform certain functions. For example, when changing configuration parameters, the web server can conveniently use the shell to instruct the PBX to reload its configuration. This is commonly done using the PHP command shell_exec; because it is so popular there is even a special back-tick operator for this. It could be that when you set the username to env X="() { :;} ; reboot" /bin/sh -c "Joe Doe" your system will have some fun with reboots.

Unfortunately it seems that not only the web servers and PBX software are a problem, but also standard programs like dhclient and OpenSSL. That means that the appliances running the PBX software could be a problem. For example, when a DHCP server in the LAN send out DHCP packets that cause the dhclient to pass junk to the configuration hooks, your PBX host could be in trouble.

This is especially the case for CPE-based PBX where other users in the LAN can easily send out packets in the LAN. The PBX itself is not the problem, like stated above. But the snom and Vodia mini appliances as well as the snom ONE plus are using OpenSSH and dhclient. This makes it necessary to update their bash. Because they are using more or less standard Linux distributions, it should be possible to log in and perform the standard steps published in many places to update the bash code. The PBX itself cannot help here; it does not provide a mechanism to upgrade programs on the OS level.

Hosted PBX that run in environments where attackers will have a hard time setting up DHCP servers should be fine. Most hosted PBX have IP-based OpenSSH filters anyway, so that the damage on the OpenSSH side should also be limited. It would be a good time to make sure that only certain IP addresses can access your hosted PBX.

What is particularly shocking is that the bug seems to be in bash for decades. Thinking about the latest data security scandals, this must have been an entry door for all sorts of people for many years. I am glad we are now able to close those doors and make this world a lot safer against unauthorized access.

Let’s see what is next.