Flaws Threaten VoIP Networks?

jdkane writes "CNET News reports that security flaws have been found in products that use VoIP and text messaging, including those from Microsoft and Cisco Systems. What's interesting, in Microsoft's case, is that the Internet Security and Acceleration Server product that's also affected is designed to help protect companies' networks from online attacks. Specifically, a filter used in the server that secures VoIP communications is vulnerable to the flaw."

Comments

Imagine That

[somethinghollow]

Imagine that... Microsoft making a product with security flaws! Someone call the press...

Re:Imagine That

[pvt_medic]

but the better part is the fact that this was the security filter is the flaw. So maybe Microsoft should give up on the whole security thing.

Re:Imagine That

[bfree]

Vulnerable (updates available): Cisco and Microsoft
Unknown: Avaya, Fujitsu, Hewlett-Packard, Lucent and Nortel
Safe: Apple, Hitachi, NetBSD, Red Hat and Symantec
Is that a point for Security through open source as the two open products are already in the safe pile?

Re:Imagine That

[Alien Being]

"...where could you find a reporter who would care?"

Nation Public Radio (WBUR 90.9MHz to you fellow Bostonians) for one. Believe it or not, the great unwashed masses are starting to become aware of the problem with Microsoft.

Re:Imagine That

[DAldredge]

Since Red Hat is safe and I to take it that SCO is safe also?

Re:Imagine That

[interiot]

Well, various Java VM's have had problems in the past, does that mean we should just throw them away? Similarly for user-privilege-separation in the linux kernel. The whole reason we write narrow pieces of code that focus on security is that we realize that it's impossible guarantee a piece of code is bug-free. So instead, we do the two things that helps clear out bugs the best: we make the important security-related code as small as possible, and we give it time for people to find bugs and for us to fix them. After a while, you have a simple and mature piece of code that enhances the security of everything else, allowing the code it protects to be fast-changing and complex yet. It really seems like the right way to go to me. Finding and repairing flaws over time is how you gain maturity.

You linked to Microsoft's patch

[ObviousGuy]

So it seems they've already fixed the problem.

Should we blame lazy sysadmins for not keeping their systems patched?

Or should we blame Microsoft?

Re:You linked to Microsoft's patch

[Creepy Crawler]

But when the patch is 40MB that "fixes" many things that were never broken, can you trust the patch?

Knowing MS, they'll offload packs that will break something else, or require deps on Service Packs. How do I know that upgrading Win2K SP2 to SP4 wont break the medical reporting server?

Re:You linked to Microsoft's patch

[Creepy Crawler]

Here's why we dont consider Linux/Unix:

http://www.despair.com/consulting.html

Simply enough, it doesnt break once you set it up. Windows setups break on a regular basis, and my employers want yet more and more money.

Consulting with the "good old boy" businesses are the hardset to get Linux in.

A flaw in a Microsoft product?

[caston]

If that's impossible than this isn't slashdot.

Thats nothing

[WillRobinson]

I saw that embeded XP beat out linux for Radio Shacks POS.. Wait tell the hackers get into that system..

Wonder why we are fed-xing all these remote control cars to russia?? Must be popular there..

Not to defend Microsoft

[silconous]

But Cisco is just as vulnerable and wider spread as IOS 11.3 and greater is flawed

Give them a break

[odeee]

The same flaws affect many products - not just Microsoft. And the flaws are H.323 flaws - not necessarily ones introduced by Microsoft.

In Cisco products - they are also vulnerable - and particularly when used as firewalls or edge devices.

But then again it's more fun to blame MS isn't it ;-)

Great quote

[fiendo]

"It is kind of the same situation that we have seen--a certain level of human error is going to be present and that is true even for security software," said Stephen Toulouse, security program manager for Microsoft.

Wow that ought to really bolster a customer's confidence: NOt only are you saying this type of mistake is common in your experience, your excuse is "Hey we're only human"! Uh isn't that why you're supposed to have quality assurance?

wow

[ThePretender]

Several other companies also produce products that may be affected, but as of midday Tuesday only Cisco and Microsoft had issued advisories and patches.
Wow. While other companies are investigating, the MS patch machine has already spit one out. Give 'em a little credit. Nah, this was just lucky hehe

ISA's Track Record is very bad

[tyler@mango.net.nz]

Since Microsoft released their "Depend on certified security" firewall, it has had 8 Security Bulletins http://www.microsoft.com/technet/treeview/default. asp?url=/technet/security/current.asp?productid=11 0&servicepackid=0&chkcritical=on&chkimportant=on&c hkmoderate=on&chklow=on&seldaterange=0&txtdatestar t=&txtdateend=&submit1=go) (and far more holes, due to Microsoft's 'monthly cluster together all the bugs we found this month and call it one hole deal.') I have installed about 20 of these fine things, and the amount of bugs and hotfixes we have found and needed to get it amazing. Microsoft Proxy Server only had ONE security hole. In fact, Proxy Server v1.0 was a single DLL which slid into IIS4! Proxy Server 2.0 SP1 could fit on a floppy. The problem is everyone uses ISA, because no other firewall I have found can provide the following. 1. Basic Reporting on Users (jo used x MB and went to these web sites.) 2. Tie in to Active Directory, so we don't have to setup and maintain another directory.

What about Open H.323

[Anonymous Coward]

What about Open H.323.
Anyone know whether that project is going to be
suffering the same vunerability ?

New commercial slogan?

[phaetonic]

*walks and stops in one place* Can you hack me now? ... Good. *walks and stops in one place* Can you hack me now? ... Good.

meh...

[netwiz]

just a buffer overflow. I'm not really surprised; sooner or later this was going to happen. I'm just surprised that it popped up in Cisco's case.

Altho, as I think about it, I get the feeling that Cisco got a bunch of network multimedia handling code from MS. I remember back in '98 or '99, they announced a software partnership w/ MS, causing much hand-wringing on /. to the effect that we might see NT-based routers. IOS is too heavily leveraged in Cisco's products, but the actual processes and services that run on it could come from anybody.

The fact that this looks to a few vendors (MS and Cisco being the biggies), and knowing how MS looks to diversify only makes me wonder how much of MS's wonderful code has managed to worm it's way into the other devices I use...

Hmm... Maybe this had something to do w/ all the dreadful STP and bridging issues I had on the Catalyst 8540 platform...

Re:meh...

[afidel]

Actually all of the effected Cisco products are in fact services that run on Windows. I know that this fact was a big concern among quite a few engineers at Cisco that wanted to port CallManager to L/Unix so that OS vulnerabilities wouldn't affect the stability of a product that they were aiming at Enterprise customers. Of course management went and did the exact opposite by tying the multimedia capabilities of CCM to an Exchange backend =(

It's not MS, it's VoIP -- expect more

[Anonymous Coward]

It's not (juts) MS here that is having a problem. Bet on having a whole buncha security reports trickling in over the next few years with VoIP.

1. It's an immature technology with immature implementations -- it's not shaken down yet to get all the flaws out (not just coding, but conceptual)
   
2. The products and protocols (i.e. SIP (Silly Improvised Protocol)) are very ambitious and attempt to provide for making voice calls, IM, centrex features, user interaction with end point interfaces, presence, and emergency services, and cook your breakfast, too. Combined with #1 above, security flaws and problems are going to abound.
   
3. Due to the ambitious, broad, and sprawling nature of the protocols and products, interoperability is going to be strained and painful, especially until a few dominant players shake out -- again expect problems due to interoperability side effects.
   
4. As VoIP products and service spread, along with a plethora of devices, it is quite possible that a killer app or a brand new application shows up -- that manages to stretch the implements in unforeseen ways. (i.e. cookies with HTTP). Once consumer fads and marketing start driving the product development tooooo fast, expect more flaws until things mature.
   

Taken all together, VoIP should be deployed very carefully in places where network security is important. You might even run into a case where even if your computer network is completely separate from the Internet, but you use VoIP over the internal LAN via a IP PBX, someone might hack your phone/VoIP endpoint through the encoded voice stream and gain access to your LAN. Stranger things have happened.

Grass is always greener...

[seigniory]

Percentage-wise, I'd bet a meeelion dollars that the folks here on /. are much more familiar with VoIP, TCP/IP, Cisco, MS, etc. than they are with whatever the heck the kids are using these days for enterprise analog voice networks.

Is it any suprise that everyone on here, pulling from their "wide" experience on both types of networks, thinks that things are oh-so-much worse with VoIP than they were/are with analog?

Look: vulnerabilities exist everywhere. If you had more people on this board that do analog telephony as a hobby/job than do PCs/*nix/etc. the articles would all be about Lucent/AT&T's switch vulnerabilities and how we should all switch to the "new bulletproof VoIP" stuff I keep hearing about.

I'll also bet *2* meeeeeelion dollars that if MS wasn't mentioned in the article, that nowhere near as many people would be jumping on this (although that's a big fat DUH).

"VoIP" is not a protocol

[Frater 219]

Slashdot editors, technical journalists, and others writing serious articles on the subject would be well-advised to drop terms such as "VoIP security flaw" or "products that use VoIP". Voice-over-IP is a general application category, and gives very little help in discerning whether an issue affects a particular site or product.

Suppose that a new bug were described as a "file sharing security flaw". Now, does that affect Samba? FTP? NFS? Kazaa? File server bots on IRC? One expects good technical reporting to mention the affected services -- or better yet, actual products -- rather than simply describing a general application category.

Specifically, in the VoIP application category, there are two major signaling protocols in use: H.323 and SIP. The last round of "VoIP security flaws" affected SIP software. The current discoveries affect H.323. Describing both as "VoIP flaws" and suggesting that the application domain itself is "threatened" is really quite silly. It is as if someone suggested that a certain bug in IIS and another in Freenet together suggested that "file transfer" on the Internet were threatened.

(For those who don't know much about VoIP: H.323 is the older of the two protocols, and is closer to the "telecoms" way of doing things. It was, IIRC, originally connected to ISDN. SIP is newer, and closer to the "Internet" way of doing things -- if you look at packet captures of it, they look vaguely reminiscent of HTTP, only they're UDP.)

Re:"VoIP" is not a protocol

[binux]

... they look vaguely reminiscent of HTTP, only they're UDP.)

Not just vaguely reminiscent. SIP message formats (request/status line followed by headers) are pretty much like HTTP headers. The response codes like 200 (OK), 404 (Not Found) too are from HTTP. SIP implements authentication using the HTTP digest authentication scheme. Most of the early SIP implementations were on UDP. TCP is however the mandatory transport to be supported by SIP end-points and servers. SIP also works over TLS.

Great opportunity

[Jonboy X]

Cool! Now if you leave voice mail over 2 minutes long, instead of an annoying beep, you get root access!

Love those buffer exploits...

Re:You should read this before committing to Linux

[Anonymous Coward]

But Windows rests on a 20 year old operating system.

Muh? Granted the parent poster is a troll, but there's no need to lie in response.

Windows NT 3.1 - a 32-bit operating system built from the ground-up was released in July 1993 (there was no NT version 1.0 or 2.0, they skipped ahead to keep up with the Windows 3.1 version number). As anyone who tried to run DOS games on Windows NT / 2000 / XP can tell you - it is definitely *NOT* based on DOS.

Taking release dates, Windows NT is two years younger than Linux - which was released in August 1991

If you're going to lie, at least do it convincingly. (The original poster was refering to Windows NT 4, not Windows 95 and 98, which admittedly sit on top of DOS).

Pragmatically, though.....

[liamk]

I've received several calls and emails from customers today asking about the relevancy of the Cisco Security Alert. By and large, I only deal with enterprise/corporate-type customers (not large VoIP service providers), and I install a ton of Cisco VoIP products, so this comment really only applies to that segment of the marketplace.

I don't think that this is going to be as large of a problem as Cisco's earlier issues. Although a worm could target home users running IP telephony applications on their PC's, this vulnerability is non-replicating and the potential for abuse is rather limited.

Basically, there are two major Cisco product lines that are affected by this bug. The first is Cisco's VoIP infrastructure products: the Cisco CallManager server, Conferencing Server, Softswitch and IOS-based routers running H.323 services, among others. Except where the public has access to VoIP services over the Internet, these servers and routers are located on the inside of a firewall. In a best-practices network design, all access to these servers and routers is either via the internal LAN or through a secure VPN connection over the Internet (or any other public network, for that matter). I would find it very unusual to have these services available publicly. If I left a Cisco router with POTS access and an easily guessable dial peer on an Internet-accessible LAN, the potential for toll fraud would be enormous (free calls, lots 'o free calls).

The second group of products that are vulnerable are Cisco routers performing NAT and firewall services. Cisco's Content Based Access-Control (CBAC) -- a "dynamic firewall" technology -- is also vulnerable to the H.323 DoS attacks in the same manner as the Microsoft IAS server. Once again, unless H.323 ports are open to unrestricted access from the Internet, routers are not vulnerable from random outside attacks. Traffic that originated from behind the firewall would be able to disrupt services, however it's much easier to apply an access list to track and block the offending traffic than it is to prevent an external DoS attack.

What's my point? I don't see a widespread attack being able to disable servers and routers on a large scale. Unless attacks are originated from inside a corporate firewall, the potential for disrupted services are minimal. I'm sure that large VoIP service providers are scrambling to patch and secure whatever systems possible - however, they are much better equipped to handle this issue than a Mom and Pop business who happens to have a CallManager server (at least we hope).

For people who are running these products, I'm recommending a thorough review of external firewall policies to make sure that there aren't any exposed H.323 ports. I'm also recommending an upgrade when it's feasible, but IMHO, there aren't many situations that would require burning the midnight oil to install patches.

Just my $.02.

Expect such flaws in 2.6 soon

[kris]

The current H.323 flaw is based on bugs on the ASN.1 parser used in these products. The big bugs in almost all SNMP implementations a year ago or so also was based in ASN.1 parsing failures. Many openssl bugs are based in ASN.1 parsing failures.

The linux kernel 2.6 just got ASN.1 parsing INSIDE THE KERNEL in order to implement AUTH_KERB as part of the NFS/Kerberos client. Expect ASN.1 parsing based bugs inside the Linux kernel real soon now.