Slashdot Mirror
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."
Now the NSA will have to go to Plan B.
"National Security is the chief cause of national insecurity." - Celine's First Law
Those aren't flaws: they're NSA features.
http://blog.azimuthsecurity.com/2013/06/attacking-crypto-phones-weaknesses-in.html
Slow news?
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.
Languages like Ada/Spark and Haskell: Yes. The languages you mention: not really.
Is Jitsi ( http://sourceforge.net/projects/jitsiportable/) affected?
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!
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.
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)
I assigned CVEs here: http://openwall.com/lists/oss-security/2013/06/30/2
Is Jitsi affected? I think it uses ZRTP.
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?
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.
First he shoots a poor kid during his neighborhood watch, then writes a library with security vulnerabilities? Sheesh.
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).
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)
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.
So no solution is better than an imperfect solution? That's a foolish line of reasoning I would think.
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
You're going to die eventually anyway, so you wouldn't really be better off, if you still kept trying to stay alive.
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.
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.
Is Jitsi affected? It uses ZRTP.
And why is my post not showing up?