FreeSWITCH

Many people have asked over the years why FreeSWITCH bundles so many libraries. The core developers are certainly aware of the downsides of this approach. We know it makes it difficult to stay on top of updates to these libraries. We know well ... [More] that it complicates inclusion of FreeSWITCH in the major distributions. And we certainly know that it makes a clean build of FreeSWITCH take a very long time with all modules enabled.   But in every case where we've bundled a library with FreeSWITCH, there was a reason. Here are some of the major ones:   * We've become the upstream for Sofia-SIP. The original developer has moved on, and we've taken over maintenance and improvements to the library.   * The author of Spandsp, the inimitable Steve Underwood, now commits updates to his library directly into the FS source tree, so ours is always the most recent version.   * SQLite breaks in the sort of highly-multithreaded model that we use in FS, and we were never able to get our patches included in upstream, so we've essentially forked (which is encouraged by the SQLite project). While FS can build with more recent upstream versions of SQLite, it is very unstable.   * Many libraries we need, such as the most recent one, libv8, have (or at one time had) obsolete versions packaged in the major distros. Debian, for example carries 3.14 and we need 3.24 to make mod_v8 work at all.   * At one time, CentOS had patched libraries such as curl in ways that just completely broke them in our use case (e.g. they linked against libraries such as NSPR unnecessarily), so even if an apparently suitable system library was there, we couldn't use it.   * For many years, distros packaged major libraries built without thread safety.   * Many libraries which may now have acceptable versions in most major distributions did not at one time, and someone would have to go through each major distribution and verify that the library there is now actually acceptable, perhaps updating FS to use a newer API, and test the feature under load.   * When two distributions carry incompatible versions of the same library, it becomes very difficult to support both when building against system libraries. For Debian alone, we currently support sid, jessie, wheezy, and squeeze, and library versions and availability vary greatly between those releases.   * Though strictly distinct from the issue of bundling, we believe in the merits of static linking certain libraries. We sympathize with many statements Rob Pike has made about this issue, and with a piece by Roman Shaposhnik you can read here:   https://blogs.oracle.com/rvs/entry/what_does_dynamic_linking_and   ...and comments on that piece by Anthony here:   http://www.freeswitch.org/node/56   * Building on BSD, OS X, and Windows are project goals, and they do not provide these libraries.   We're happy to accept patches that would make FreeSWITCH build optionally against system libraries. No one has yet(!) stepped up to do this work. And while it would be a very valuable contribution, it's just not a priority for the core developers who focus on other important work.   If you're interested in helping out here, we're interested in helping you. Get in touch with us.   -- Travis Cross   [Less]

We like to stay on the cutting edge, so the FreeSWITCH master branch has moved to Lua 5.2 for mod_lua. If you need to stay on Lua 5.1 for awhile, fear not, we've added a new folder, src/mod/legacy in which you'll find the old module. The FreeSWITCH 1.2 stable branch will also be keeping Lua 5.1 for its lifetime.

Today Peter Olsson's new mod_v8 was merged into FreeSWITCH. FreeSWITCH has long allowed writing call control in Javascript; now that Javascript is powered by the V8 engine -- the same engine that underlies Node.js and the Chromium web browser.   Be ... [More] sure to send Peter your love, but more importantly, reports on how the new mod_v8 works for your scripts. We believe mod_v8 should be a drop-in replacement for mod_spidermonkey.   [Less]

We'll be having Peter Olsson join us on today's conference call at 1800 UTC (which you can reach at sip:[email protected] or http://conference.freeswitch.org/). He'll be talking about his new module, mod_v8, which is intended to replace ... [More] mod_spidermonkey.   This is exciting as the V8 Javascript engine is the clear way forward for supporting Javascript in FreeSWITCH. V8 has significant performance improvements, has an active upstream, and underlies other major projects like Node.js.   Join us if you can to learn about this new addition to FreeSWITCH.   We're making some changes to the format of the conference call for 2014. We'll be starting the call on time, and trying to keep the length of the call to under one hour so more busy people can join in.   -- Travis Cross   [Less]

The question of why FreeSWITCH uses so many embedded libraries comes up all the time. We first addressed this back in 2007, and wow has time flown and FreeSWITCH grown up!   Many users and new faces question this practice on a regular basis, so I ... [More] thought it might be time to revisit the reasons why. I thought about writting a whole new article on this subject, but having gone back and re-read the original articles, I think its best to just link them here.   For the original post on FreeSWITCH.org see http://www.freeswitch.org/node/56 and for an indepth explanation see Roman Shaposhnik's write up from when he was Sun Studio Linux Architect, Engineering Manager at https://blogs.oracle.com/rvs/entry/what_does_dynamic_linking_and   [Less]

[This story was delayed from 10/24 to give a vendor time to respond. As it turned out, that vendor decided to take no action.]   Cal Leeming (foxx on IRC) was kind enough to join our weekly conference call to raise awareness about the importance of ... [More] secure provisioning.   Many providers put configuration files for IP phones on publicly-accessible servers. Often these files are neither encrypted nor protected by any form of authentication. All you need to access these files is the URL scheme used by the provider and the MAC address of the phone. As we'll see in a moment, this is in fact essentially required for zero-touch provisioning to work as it does today.   Let's say you want the contents of some of these files. How might you find the URL scheme used by a provider? Previously if you couldn't find it by guessing, you would probably need to get a phone from that provider and then either extract the firmware or watch the traffic with Wireshark. Having to do that for many providers, while not infeasible at all, does present something of a barrier.   Fortunately (for the bad guys), phone manufacturers have decided to adopt a technique (I hesitate to say 'technology') called zero-touch provisioning or RPS (Redirection and Provisioning Service). The idea behind RPS is that providers can remotely provision new phones they've never physically handled at all.   After a phone is sold to a service provider (perhaps via a wholesaler), the service provider makes an API call that tells the manufacturer they now own a particular phone, identified by MAC address, and to where requests for the phone's configuration should be redirected.   Now when a request is made to the manufacturer's publicly accessible server for the phone's configuration, their server redirects the request to a file on the provider's configuration server. If an attacker simply knows the MAC address and manufacturer of a phone, she can make a request to the manufacturer's RPS server, which will redirect to the provider's server, which -- more likely than not -- will hand over the plaintext file containing the phone's configuration.   With this configuration file, the bad guys can impersonate the user. That would be bad enough, as it would likely give them access to the user's voicemail or other privileged services.   More likely, however, the bad guys will be interested in committing toll fraud. They'll use the stolen account to pump a large volume of calls to high cost foreign rate centers where -- through complicated business mechanisms -- they'll be able to collect a portion of the toll charges paid by the victim and the other intermediating carriers. The dollar amounts involved in this kind of fraud can be shockingly high.   But we're getting ahead of ourselves. How will the bad guys find a valid MAC address for a phone?   As it turns out, this isn't difficult, and RPS makes this much easier. MAC addresses are 48 bits long, so there are 2^48 of them. The first 3 bytes (24 bits) of the address compose the Organizationally Unique Identifier (OUI). One or more of these are assigned to organizations like Yealink or Snom. This leaves 24-bits for the manufacturer to assign unique addresses to their equipment. In practice, for a particular model of phone, a manufacturer might assign addresses out of a space as small as 16 bits, and they are likely to assign these nearly sequentially. Therefore, if you know the MAC address of just one phone, and search the surrounding 2^16 addresses, you're likely to find many valid phone MAC addresses.   In Cal's testing, he found he could make at least 1000 requests per second against manufacturers' RPS servers. It's likely that determined bad guys with a cluster of systems could do better.   1000 requests per second (should we say 1000 'RPS'?) is about 2^10. So we can search a 2^16 space in only 2^(16-10) = 2^6 = 64 seconds. And because of RPS, we don't have to repeat this search against N different service providers. We simply target our search against the manufacturer's RPS server and they'll tell us who the service provider is and where we can find the provisioning file.   This really is as bad as it sounds. What's perhaps worse, however, is how little surprise there was on our call. This is not a disclosure in the common sense of the word. Everyone familiar with these systems already knows about this problem -- though there was some debate on our call about whether there really may exist people dull enough to both understand the system design and miss this problem (I doubt it). The mission instead is to remind people that this flaw, though widely accepted, is a recipe for failure that should not be tolerated. As soon as attackers organize around exploiting this weakness, the damage to the industry could be massive.   Even more problematically, there is no way for service providers -- without assistance from phone manufacturers -- to completely address this weakness without forfeiting the benefits of zero-touch provisioning. Providers can configure their provisioning servers to require a valid username and password, and then assign unique credentials to each phone. When the phone supports HTTPS provisioning, this would be reasonably secure as long as you could securely deliver the credentials.   (Some phone firmwares allow the service provider to encrypt the configuration file using a key the server shares with each phone. This is isomorphic, for the purposes of our discussion.)   But that's exactly the problem with zero-touch configuration in its current form. The first time the phone connects to your servers (via an RPS redirect), it won't have any credentials. You'll have to decide whether to issue the phone the credentials it will use in the future. If you do so, you'll also need to never issue this phone credentials in plaintext again (otherwise you won't have improved security at all). But you have no way of knowing whether what's connecting to your servers is the phone you sold, or an attacker impersonating it. How can you decide whether to give it the credentials? If you make the wrong choice, you'll open yourself up to toll fraud, and you'll lock out the actual phone.   The obvious solution to this issue is for the manufacturer to include a unique private key with each phone (ideally via a TPM) such that the phone could securely authenticate itself to servers. Doing only this, however, would complicate the sale of phones through distribution as the public components of the keys would need to be distributed and managed.   A more sane solution would be to sign each phone's certificate with the manufacture's private key. The phone could then provide its signed public component when authenticating to the service provider, and the provider could check the signature against the manufacturer's public key component. As long as the manufacturer securely created and managed their certificate authority, this would work fine.   There are other solutions that are somewhat less elegant, such as dispensing with "zero-touch" and forcing the entry of a PIN-like code on the phone.   It will be interesting to see how manufacturers respond to the increased attention being focused on this issue. Will they take down their RPS servers? Will they move to more secure provisioning models? Or will attackers need to inflict large financial damage to their customers before the manufacturers respond? Time will tell.   -- Travis Cross   [Less]

Cal Leeming (foxx on IRC) was kind enough to join our weekly conference call yesterday to discuss a very interesting issue that apparently has at least one phone manufacturer in a bit of a panic.  We're withholding details for now to give that manufacturer time to react.  Expect a more detailed story here in a couple of days. -- Travis Cross

The FreeSWITCH Team is proud to announce the release of FreeSWITCH 1.2.14! Available today via git, http://files.freeswitch.org/freeswitch-1.2.14.tar.bz2, and the deb and yum repos. This is a maintenance release to address several bugs that have been ... [More] identified since the last release.   Also dont forget ClueCon Weekly Conference Call! Every Wed at 1PM EST! For more information on how to join see: http://wiki.freeswitch.org/wiki/Weekly_Conference_Call_Calling_Instructions [Less]

Bluebox-ng is an open-source VoIP/UC vulnerability scanner. It has been written in CoffeeScript using Node.js powers.  Features RFC compliant TLS and IPv6 support SIP over websockets (and WSS) support (draft-ietf-sipcore-sip-websocket-08) SHODAN ... [More] , exploitsearch.net and Google Dorks SIP common security tools (scan, extension/password bruteforce, etc.) REGISTER, OPTIONS, INVITE, MESSAGE, SUBSCRIBE, PUBLISH, OK, ACK, CANCEL, BYE and Ringing requests support Authentication through different types of requests SIP denial of service (DoS) testing SRV and NAPTR discovery Dumb fuzzing Common VoIP servers web management panels discovery Automatic exploit searching (Exploit DB, PacketStorm, Metasploit) Automatic vulnerability searching (CVE, OSVDB, NVD) Geolocation Colored output Command completion It runs in GNU/Linux, Mac OS X and Windows So this is yet another tool in the toolbox you can use to help test the security of your UC/VoIP installations. IRC(Freenode): #breakingVoIP       [Less]

Friends,     As some of you may have heard by now, our very own Brian K West (a.k.a. bkw_) is going to be marrying the love of his life, Gregory A Dunn.  The ceremony will be held on October 7th in NYC.  Please join with us all in congratulating him ... [More] and his spouse to be.  For those of you who would like to help out with the costs of the planning and ceremony, or would just like to send them a gift, his paypal address is [email protected].  No gift is too small (or too large ;-)) If you're in, or around, NYC on the 6th or 7th, we'd entertain the idea of having a FreeSWITCH Users' dinner somewhere in the area on one of those two nights if there's enough interest.  Feel free to email me privately (at [email protected]) if you'll be in the area and interested in congratulating them, in person, over dinner. -Ray [Less]