There was a bit of a blowup at Trixbox and Fonality these past couple of weeks over Trixbox supposedly including spyware that collects all manner of information and then phones it home to company headquarters.
Then the story expanded to the phone-home script opening a door to a remote attacker executing random commands on your system at will. Before doing any further investigation, most savvy admins are prepared to believe this, because we're always fighting back against unethical and even illegal behaviors like this from companies who think they're above the law; that we, their customers, are packs of thieves scheming to rob them blind, and therefore they are justified in using whatever means they think are necessary to defend themselves. You can see how a big giant GlobalCorp chock full of attack lawyers and security guards would feel threatened by individuals who want to buy their products.
But before we march on Fonality with flaming torches and sharpened pitchforks, let's not go all wonky, but dig into the issue and see what's going on.
First, the easy stuff: Fonality admitted that there is a phone-home script, /var/adm/bin/registry.pl.
Now let's dig into the hard stuff: What's the problem, and what does this script really do? Here is a summary in a nice, easy-to-understand bullet list:
- There was never any disclosure that the script exists
- There was no disclosure as to what data the script collects or how
- The script runs every 24 hours, and operates by first contacting a remote server at Fonality to collect a list of commands to run
- Then it runs this arbitary list of commands without so much as a 'Mother-may-I'
- It opens the door to a man-in-the-middle attack; which, if it were successful, would give an attacker free reign on your system
- It opens the door widely to an inside attack; that is, by/from a disgruntled or dishonest Fonality employee
"Trixbox has always "phoned home" so there is nothing new here.. It sends some anonymous usage stats so we know how many active systems running what versions are out there."
But to me, that assessment doesn't hold water, nor does it for a whole lot of other people.
A big problem with that is the belief that it's OK to collect all manner of customer data without disclosure or asking permission.
It is true that it's a common practice, and that businesses have long had the habit of acquiring as much customer data as possible without disclosure, and, even worse, buying and selling it for all they can get. But that doesn't make it right, not even when it's supposedly harmless, anonymized data.
We have no way of verifying that it really is anonymized, which would take some deliberate effort, because even the simplest network communication contains all kinds of identifiers. We have no way of knowing exactly what commands are run and what information is collected because it's possible to change those commands every day; and anyway it's not Fonality's property.
It's illegal for a Peeping Tom to peer through the windows of your house, so how can it be right for anyone to sneak into your computer? What is so important that this needs to run daily, anyway? Nothing that's important to the customer, as far as I can tell.
Mr. Garrison says disabling it is easy: It runs from a cron job, so just delete the pertinent cron entry. That seems pretty weak to me, since it leaves the script on your system. Deleting the script seems a better way to handle it.
As you read through the Trixbox forums where this is discussed, another factor becomes clear: Mr. Garrison and the nice folks at Fonality were too slow to grasp the seriousness of this issue. Not only is it a breach of trust, but the script itself is sloppy and lacking basic sanity and safety checks. This quote speaks volumes:
The real Fix
Mr. Garrison's post entitled Ttrixbox CE audit tool official statement and "fixes" issues an apology and describes the fix, which was released December 19th.
I have no reason to doubt the integrity of the folks at Fonality. In fact I hold them in high regard; I think they're good people with good products and hardly any detectable bad intentions. (That's a tiny joke there, Mr. Lyman.) They listened to their users and fixed the problem in record timesix days is impressive.
As Mr. Garrison said, everything including the code is open, so it's completely auditable. An easier way to see if anyone is phoning home is to sniff your own network traffic and see for yourself what's going out over your wires, and read your logfiles, and verify for yourself what processes are running and what they're doing. These are routine admin chores, and while they're not exactly a rollicking good time, Linux users have hundreds of powerful tools at their disposal just for this kind of work.
This incident does illustrate a question everyone should ask themselves: why should I trust this vendor with my stuff? Our trust in the businesses we deal with is betrayed every dayour personal data gets stolen, which is a joke anyway since it is bought and sold so freely with never a "please may I, and you'll get a cut of the swag." The telcos store terabytes of call records, retailers collect detailed purchasing data, and the three big credit reporting agencies all but control our destinies.
Don't even get me started on sweeping warrantless searches that way too many businesses just roll over for. Thanks a lot. May your rights be defended as vigorously as you have defended ours.