Flaws In ZRTPCPP Library, Used In Secure Phone Apps

Gunkerty Jeb writes "A security researcher has uncovered a number of serious vulnerabilities in one of the core security components of several secure telephony applications, including the Silent Circle system developed by PGP creator Phil Zimmermann. The vulnerabilities in the GNU ZRTPCPP library already have been addressed in a new version of the library and Silent Circle has implemented a fix, as well. ZRTPCPP is a library that implements the ZRTP protocol that Zimmermann and others developed to establish secure sessions over a pre-existing connection. Silent Circle, which sells a cryptographically secure mobile phone application, and several other products implement the ZRTPCPP library, and Mark Dowd of Azimuth Security has identified several vulnerabilities in the library that could give an attacker the ability to get remote code execution. Dowd said that the bugs can be exploited by remote, unauthenticated users."

Comments

Drats, foiled again...

[msauve]

Now the NSA will have to go to Plan B.

why bother?

[stenvar]

Nothing on an Android or iPhone device is ever secure; it's too easy for the NSA or other organizations to install Trojan horses. And installing a crypto app from the market is like painting a red bulls eye on your phone.

Re:why bother?

[gl4ss]

Nothing on an Android or iPhone device is ever secure; it's too easy for the NSA or other organizations to install Trojan horses. And installing a crypto app from the market is like painting a red bulls eye on your phone.

well.. that's why everyone should install a crypto app from the market then..

Re:why bother?

[AliasMarlowe]

well.. that's why everyone should install a crypto app from the market then..

Simply installing such an app is of little use per se. One must install and use it. It's strongly recommended that it be one of the FOSS apps, as they are less likely to have back doors open to the NSA or other malefactors.

Re:why bother?

[adolf]

It's strongly recommended that it be one of the FOSS apps, as they are less likely to have back doors open to the NSA or other malefactors.

I'm not willing to accept the notion that the device itself isn't backdoored by default.

Re:why bother?

[peawormsworth]

Nothing on an Android or iPhone device is ever secure; it's too easy for the NSA or other organizations to install Trojan horses. And installing a crypto app from the market is like painting a red bulls eye on your phone.

Any door can be broken down with enough force and putting a lock on it is like painting a red bulls eye for burglars. Better to not install a lock on the front of your home or put an alarm in your car.

Re:Remote code exploit in Crypto

[aaaaaaargh!]

Languages like Ada/Spark and Haskell: Yes. The languages you mention: not really.

CVEs assigned

[seifried]

I assigned CVEs here: http://openwall.com/lists/oss-security/2013/06/30/2

Re:CVEs assigned

[BitZtream]

So? Slashvertising doesn't mean anyone actually cares that you too can copy and paste something someone else wrote to a website.

A secure PHONE application? Funny!

[Marrow]

When the phone company, the NSA, the FBI, and any of their contractors can literally climb into your phone at will and change anything they want to change? Heck, has anyone even checked to see if IP forwarding is turned off on these things?

Great

[Coppit]

First he shoots a poor kid during his neighborhood watch, then writes a library with security vulnerabilities? Sheesh.

Implementation bugs, not protocol bugs

[billstewart]

Yes, I'm ignoring your joke; sorry :-)

Fortunately, while these bugs are annoying and may break a number of different programs, they're bugs in the implementation code, not bugs in the communication or crypto protocols themselves. That makes them much more fixable. (Perhaps harder to detect in the field, but fixable.)

Re: Jitsi

[arglebargle_xiv]

No, Jitsi is in Java and it doesn't use ZRTPCPP. Also there are no buffer overruns there.

Exactly. Java has more than enough vulns to go around without needing a buffer overrun as well.

FYI: iPhone not among those vulnerable

[tlambert]

Nothing on an Android or iPhone device is ever secure; it's too easy for the NSA or other organizations to install Trojan horses. And installing a crypto app from the market is like painting a red bulls eye on your phone.

This particular library is GPL'ed and therefore can not be used in iPhone Apps without violating the App Store terms of service agreement. So this library, and therefore your statement based on the vulnerability of this library, doesn't apply to iPhones.

Re:FYI: iPhone not among those vulnerable

[stenvar]

That has nothing to do with this library. Apple, Google, and almost any government and telecom can push arbitrary code onto your phone. Android and iPhone are both equally vulnerable. It doesn't matter how Apple runs its markets or how they review their software or how secure their OS may be; if you can't trust the update channel, you can't trust the phone.

Re:FYI: iPhone not among those vulnerable

[tlhIngan]

This particular library is GPL'ed and therefore can not be used in iPhone Apps without violating the App Store terms of service agreement. So this library, and therefore your statement based on the vulnerability of this library, doesn't apply to iPhones.

Not necessarily. The GPLv2 is perfectly compatible with the App Store in all its terms. The only thing is the App Store requires that if you use anything that's not of your copyright, you are licensed to use it. Since the GPLv2 allows it as long as you provide source, it's perfectly legitimate.

GPLv3, by its nature is incompatible with all App Stores because of the "Anti-TiVoization" clause. In some App Store licenses, like Microsoft's, it's explicitly stated. In others, it's implicit (you aren't allowed to use GPLv3 because you'd violate the whole "licensed to use it" clause - if you can't fulfill the requirements of the GPLv3, you're not able to use its exemptions and thus copyright law says you can't use it).

Of course, this library, being a GNU one automatically falls under GPLv3+. But if it existed under the GPLv2 at any point, that is still legitimate and valid. And vulnerable.

If you think the VLC thing prohibited App Stores and GPL, it didn't. All it did was one contributor working under Nokia to send a copyright notice to Apple, who was patiently waiting for a resolution and who finally had enough and removed it. Apple will not wade into copyright issues and will remove your app if a copyright holder objects. The VLC iOS team did not provide sufficient counter notice and Apple after a month, gave up.

Re:FYI: iPhone not among those vulnerable

[tlambert]

That has nothing to do with this library. Apple, Google, and almost any government and telecom can push arbitrary code onto your phone. Android and iPhone are both equally vulnerable. It doesn't matter how Apple runs its markets or how they review their software or how secure their OS may be; if you can't trust the update channel, you can't trust the phone.

Sure; but you post is off topic, since we are talking about this library (reread the original title, original summary, and original article, if you are confused). A flaw in this library does not imply an iPhone vulnerability.

Re:FYI: iPhone not among those vulnerable

[stenvar]

My post is exactly on-topic: I pointed out that it doesn't matter whether ZRTPCPP is secure or not because both Android and iPhone are intrinsically vulnerable to the attacks that ZRTPCPP is supposed to guard against.

Re:A secure PHONE application? Funny!

[mlw4428]

Android phone w/ Cyanogenmod & an encrypted VoIP behind a firewalled, logged WIFI connection on a tablet without a phone radio would make it next to impossible to not be caught.