Flaws In ZRTPCPP Library, Used In Secure Phone Apps

← Back to Stories (view on slashdot.org)

Flaws In ZRTPCPP Library, Used In Secure Phone Apps

Posted by timothy on Sunday June 30, 2013 @07:28AM from the fix-is-in dept.

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."

42 comments

Min score:

Reason:

Sort:

Drats, foiled again... by msauve · 2013-06-30 07:36 · Score: 2

Now the NSA will have to go to Plan B.

--
"National Security is the chief cause of national insecurity." - Celine's First Law
1. Re: Drats, foiled again... by Anonymous Coward · 2013-06-30 07:59 · Score: 0
  
  How about this one?
Bug or Feature? by Anonymous Coward · 2013-06-30 07:37 · Score: 0

Those aren't flaws: they're NSA features.
All Fixed. by Anonymous Coward · 2013-06-30 07:38 · Score: 0

http://blog.azimuthsecurity.com/2013/06/attacking-crypto-phones-weaknesses-in.html
Slow news?
why bother? by stenvar · 2013-06-30 08:11 · Score: 1

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.
1. Re:why bother? by gl4ss · 2013-06-30 08:15 · Score: 2
  
  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..
  
  --
  world was created 5 seconds before this post as it is.
2. Re:why bother? by Anonymous Coward · 2013-06-30 09:04 · Score: 0
  
  It'll be like one of those Where's Waldo cartoons, where a statistically-unlikely number of objects in the picture have red and white stripes.
  This is what's known as "raising the signal to noise ratio". It works very well and is usually inexpensive to produce and expensive to filter. It should be the first defense against any kind of unwarranted surveillance.
3. Re:why bother? by AliasMarlowe · 2013-06-30 09:16 · Score: 1
  
  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.
  
  --
  Those who can make you believe absurdities can make you commit atrocities. - Voltaire
4. Re:why bother? by adolf · 2013-06-30 09:25 · Score: 1
  
  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.
  
  --
  Kid-proof tablet..
5. Re:why bother? by Anonymous Coward · 2013-06-30 09:31 · Score: 0
  
  I find that TextSecure and Redphone from Moxie Marlinspike's crew Whisper Systems are both effective. They're FOSS too.
  The compression filters on Redphone need some love, but otherwise they're two great pieces of software.
6. Re:why bother? by Anonymous Coward · 2013-06-30 10:08 · Score: 0
  
  As if FOSS binaries from some untrusted 3rd parties on anybody is "free to deploy" marketplace had the best trackrecord.
7. Re:why bother? by Anonymous Coward · 2013-06-30 13:41 · Score: 0
  
  And are completely insecure if, as stated above, "the device itself [is] backdoored by default."
8. Re:why bother? by peawormsworth · 2013-07-02 06:35 · Score: 1
  
  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.
Remote code exploit in Crypto by Anonymous Coward · 2013-06-30 08:45 · Score: -1

Here we have an example of how cryptography actively lowered security against an advanced attacker. The crypto lib contain a remote code exploit, and several other issues which could at least cause crashes. Sure, those particular bugs are now fixed, but it this should make one wonder about using languages like C++ for security purposes. There may be more such bugs; its hard to know.
Languages like Python, Go, Java or Rust would have prevented bugs like that for the most part. That fact is one of the main points of languages that offer memory safety as a feature.
1. Re:Remote code exploit in Crypto by aaaaaaargh! · 2013-06-30 09:10 · Score: 2
  
  Languages like Ada/Spark and Haskell: Yes. The languages you mention: not really.
2. Re:Remote code exploit in Crypto by Anonymous Coward · 2013-06-30 09:46 · Score: 0, Informative
  
  There may be more such bugs; its hard to know.
  Languages like Python, Go, Java or Rust would have prevented bugs like that for the most part.
  So you wouldn't really be better off, if you were using one of those languages.
3. Re:Remote code exploit in Crypto by Anonymous Coward · 2013-06-30 09:47 · Score: 0
  
  The exploits were classic buffer overflows apparently. Memory safety is enough to prevent those from being remote execution exploits. The languages I listed have memory safety and avoid the danger and crash instead. Thats still bad, but not nearly as bad. There are hundreds of other languages that also have such memory safety: all we needed there was a bounds check! I'm not advocating the languages I listed there, just pointing out that they have memory safty, and C++ and C do not.
  I challenge you to get a remote execution exploit out of a buffer overflow in idiomatically written Python, Go, Java or Rust. Those mistakes just don't happen in languages with bounds checking.
  Sure, languages that also have much stronger compile time guarantees would also catch other things, and likely at compile time (not just run-time). Personally I fear using haskell (or any lazy language) in any place a timing side channel could be an issue, but I don't know if that applies here (I hope I never touch code with timing side channel issues. Thats so hard to get right in any language). Otherwise haskell seems like an excellent choice in such contexts, but I don't know it well enough to assert that.
  I wasn't suggesting which languages were good choices though, just ones that avoid basic buffer overflows, since those apparently still cause tons of issues (like the ones in this article)
4. Re:Remote code exploit in Crypto by Anonymous Coward · 2013-06-30 12:50 · Score: 0
  
  Languages you name would be painfully insufficient for this task and would have to fall back to FFI/extension modules (Guido himself said something to the effect of "Oh, just write those parts in C" when asked about CPython's performance).
  Welcome back, Buffer overflows! Good bye, Type safety and Performance! At least you left us your friend Unpredictable GC pauses.
5. Re:Remote code exploit in Crypto by Anonymous Coward · 2013-06-30 13:51 · Score: 0
  
  There may be more such bugs; its hard to know.
  Languages like Python, Go, Java or Rust would have prevented bugs like that for the most part.
  So you wouldn't really be better off, if you were using one of those languages.
  Less bugs is identical to the same amount of bugs? Only languages that prevent all possible of a particular type are better at writing secure code? That is your point right?
  Its possible to have buffer overflows in Go for example in a couple of cases. I didn't want to falsely assert using a language like Go would prevent all possible buffer overflows (Turing machine programs can buffer have buffer over flow bugs, thus all Turing complete languages can!). However, the particular cases here would have been prevented, as are basically all similar ones. If this is not considered to help, then what would be?
  If I assert things are absolutely universally true for all cases, you will blame me for being wrong about unrelated corner cases (and rightfully so).
6. Re:Remote code exploit in Crypto by Anonymous Coward · 2013-06-30 14:07 · Score: 0
  
  Yes, great job making a statement about the performance one of the languages I listed and applying it to the memory safety of all of them. Real sound argument there.
  Yes, python is slow and using it in this case (encrypting manually typed text messages in real time) might be noticeable. (Um, seriously, I suspect not, but whatever). That does not make it lose memory safety. I also listed some other language that might actually be a sane choice, but thats not the point. The point here is that there are dozens of commonly used languages that would have never lead to these bugs. The fact that we are still writing buffer overflow bugs into security critical code all over the place is ridiculous.
  To be fair, pythons horrible performance causes me to write C extensions, which have such bugs. That point is valid (and important, and even relevant), but it does not contradict mine. At best, maybe I should have removed python from that list if you consider C extensions part of the language (Which they are not, since I said Python not CPython). I could have included haskell, scala, ML, Lisp.
  And even if you pushed some of a Python version into extensions (via C or Cython), it would have still avoided some of the bugs found here, since not all were in performance critical areas. (Personally I would not take that approach, I'd just use Go)
7. Re:Remote code exploit in Crypto by Anonymous Coward · 2013-06-30 16:07 · Score: 0
  
  So no solution is better than an imperfect solution? That's a foolish line of reasoning I would think.
8. Re:Remote code exploit in Crypto by Anonymous Coward · 2013-06-30 20:44 · Score: 0
  
  You're going to die eventually anyway, so you wouldn't really be better off, if you still kept trying to stay alive.
Jitsi by Anonymous Coward · 2013-06-30 09:17 · Score: 0

Is Jitsi ( http://sourceforge.net/projects/jitsiportable/) affected?
1. Re: Jitsi by Anonymous Coward · 2013-06-30 17:21 · Score: 0
  
  No, Jitsi is in Java and it doesn't use ZRTPCPP.
  Also there are no buffer overruns there.
2. Re: Jitsi by Anonymous Coward · 2013-06-30 17:28 · Score: 0
  
  Jitsi uses zrtp4j, not zrtpcpp. Also, the actual project site is https://jitsi.org and not the link you posted.
3. Re: Jitsi by Anonymous Coward · 2013-06-30 17:42 · Score: 0
  
  Seems that it's not. It doesn't appear to use ZRTPCPP.
4. Re: Jitsi by arglebargle_xiv · 2013-06-30 23:53 · Score: 1
  
  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.
Simple Fix. by Anonymous Coward · 2013-06-30 09:42 · Score: 0

Just recompile ZRTPCPP with the CRTRPT flag set and ZZTRPCPC off and the RPCTCCT library with PZZPPTCR, use option PPTRCRCP with CRRPTCT and then link with ZZRTTPCPCRTC and RRPTZTZZ and you're all set! Doh!
CVEs assigned by seifried · 2013-06-30 11:33 · Score: 1

I assigned CVEs here: http://openwall.com/lists/oss-security/2013/06/30/2
1. Re:CVEs assigned by BitZtream · 2013-06-30 15:19 · Score: 1
  
  So? Slashvertising doesn't mean anyone actually cares that you too can copy and paste something someone else wrote to a website.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Jitsi by Anonymous Coward · 2013-06-30 11:36 · Score: 0

Is Jitsi affected? I think it uses ZRTP.
A secure PHONE application? Funny! by Marrow · 2013-06-30 12:45 · Score: 1

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 by Coppit · 2013-06-30 13:27 · Score: 1

First he shoots a poor kid during his neighborhood watch, then writes a library with security vulnerabilities? Sheesh.
CALEA by Anonymous Coward · 2013-06-30 15:05 · Score: 0

From what i can tell Silent Circle is just a VOIP company that encrypts the data channel with the idea that the endpoint only holds the decryption key. If they are indeed transmitting the VOIP traffic they would fall under a telecommunications carrier, which means they would have to adhere to CALEA. So they must have a way of decrypting the traffic.
Implementation bugs, not protocol bugs by billstewart · 2013-06-30 17:52 · Score: 2

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.)

--

Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
FYI: iPhone not among those vulnerable by tlambert · 2013-07-01 02:54 · Score: 1

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.
1. Re:FYI: iPhone not among those vulnerable by stenvar · 2013-07-01 03:12 · Score: 1
  
  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.
2. Re:FYI: iPhone not among those vulnerable by tlhIngan · 2013-07-01 15:15 · Score: 1
  
  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.
3. Re:FYI: iPhone not among those vulnerable by tlambert · 2013-07-02 03:48 · Score: 1
  
  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.
4. Re:FYI: iPhone not among those vulnerable by stenvar · 2013-07-02 07:21 · Score: 1
  
  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! by mlw4428 · 2013-07-01 05:07 · Score: 1

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.
Jitsi affected? by Anonymous Coward · 2013-07-01 07:54 · Score: 0

Is Jitsi affected? It uses ZRTP.
And why is my post not showing up?