I searched and didn't find a Seattle-specific Information Security calendar showing not only conferences, but smaller security events. So I created a new public one. And I guess that means now I'm maintaining one ;-)
If you know of something I've missed, let me know and I'll add it.
To subscribe: ICAL, XML
Full browser web view
Thursday, July 11, 2013
Tuesday, July 2, 2013
What can we learn from the ZRTPCPP / Silent Circle debacle?
As a way of background, Phil Zimmerman's company Silent Circle became wildly successful recently after Snowden's disclosures of extensive NSA data collection of telephony "metadata" and "data — including e-mails, videos, pictures, and connection logs — from the main servers of Microsoft, Google, Apple, and other leading U.S. tech companies" (1). "Mike Janke, one of the founders, estimated that the number of new customers for its subscription-based service surged by 400 percent" (2)
Mark Dowd from Azimuth Security "decided to take a brief look at the GNU ZRTPCPP library (https://github.com/wernerd/ZRTPCPP), which is a core security component of various secure phone solutions (perhaps most notably, the impressive SilentCircle suite of applications)." (3) He found several disturbing vulnerabilities in this library, including heap overflows, stack overflows, etc. that can lead to remote code execution or crashing the application. Additionally, Matthew Green found an implementation issue after a casual review.
Several applications use the same library, but most are open source free software applications. Silent Circle, however, is a commercial venture started by PGP's Phil Zimmerman. And commercial entities, especially offering a service and product set completely geared toward security and privacy should probably be expected to have an application security program and sufficient tooling and resources to validate and vet its wares. And they claimed to have had done this. However, due to the glaring bugs that were identified in the ZRTPCPP library that they mainly funded development of through its author, Werner Dittman, it is clear that their controls program to ensure security of their product is wholly inadequate and they admit as much
Even if you're the best coder in the world and think you don't need tests, what about the next person to make a change to your code or the team that inherits your code for maintenance who lacks your skill and familiarity? How can you ensure correct, safe operation now and in the future without code to check your code? What if an implementation (or security) bug is found in your code? How do you validate your fix works? How do you ensure that the same issue doesn't get re-introduced later? Unit tests can do all of this for you while you sleep and your continuous integration (CI) build runs.
Security software needs to be the leader in this. If those in infosec can't write secure software and follow secure development pracices, what are the chances for the rest of us?
Mark Dowd from Azimuth Security "decided to take a brief look at the GNU ZRTPCPP library (https://github.com/wernerd/ZRTPCPP), which is a core security component of various secure phone solutions (perhaps most notably, the impressive SilentCircle suite of applications)." (3) He found several disturbing vulnerabilities in this library, including heap overflows, stack overflows, etc. that can lead to remote code execution or crashing the application. Additionally, Matthew Green found an implementation issue after a casual review.
Several applications use the same library, but most are open source free software applications. Silent Circle, however, is a commercial venture started by PGP's Phil Zimmerman. And commercial entities, especially offering a service and product set completely geared toward security and privacy should probably be expected to have an application security program and sufficient tooling and resources to validate and vet its wares. And they claimed to have had done this. However, due to the glaring bugs that were identified in the ZRTPCPP library that they mainly funded development of through its author, Werner Dittman, it is clear that their controls program to ensure security of their product is wholly inadequate and they admit as much
"[W]e audit and test our own work and pay others to audit and test it for us. Obviously, in this case, the auditing failed. It was my understanding that all of the libraries that we used were audited, as well as all of our own code. The fact that these problems were missed suggests that there is a problem with the auditing process, that either not all of the third party libraries were audited or that somehow the auditing was not rigorous. Besides developing, testing and deploying these fixes, we will also be looking into the process." (4)When I learned the details, I wondered what can other entities that either have application security programs in place (or should) learn from this?
- Even security software companies make mistakes and imperil security -- sometimes they make some doozies
So, don't assume that because a company has a security stalwart like Phil Zimmerman or that it's in the security business that it is immune from the software security problems most everyone in every organization is dealing with.
- Open source does allow for "more eyes" to potentially make "all bugs...shallow" but it's not a guarantee. "open source can be reviewed by more people than proprietary software, but I don’t think it is reviewed by more people than proprietary software." (5)
- Use static analysis!
- Trust, but verify your application security controls
So, you paid a chunk of change to an external party to vet your code for security issues and you got a clean bill of health. That means you can rest easy, right? Not necessarily. Absence of evidence is not evidence of absence. There are myriad reasons that an external assessment did not yield results. It could have been that the tester had inadequate experience or perhaps was not thorough enough or was just plain incompetent -- all would yield equally "impressive" results. Ideally, you should be vetting your external partners to ensure they are able to catch flaws. You could even purposefully include code with known issues as a test.
- Write unit tests -- and ensure they execute as part of every build.
Even if you're the best coder in the world and think you don't need tests, what about the next person to make a change to your code or the team that inherits your code for maintenance who lacks your skill and familiarity? How can you ensure correct, safe operation now and in the future without code to check your code? What if an implementation (or security) bug is found in your code? How do you validate your fix works? How do you ensure that the same issue doesn't get re-introduced later? Unit tests can do all of this for you while you sleep and your continuous integration (CI) build runs.
Security software needs to be the leader in this. If those in infosec can't write secure software and follow secure development pracices, what are the chances for the rest of us?
- Fuzz your network code. (and fuzz your other code as well)
(1) "NSA Reportedly Mines Servers Of U.S. Internet Firms For Data : The Two-Way : NPR." Last modified 07/03/2013 04:04:55. http://www.npr.org/blogs/thetwo-way/2013/06/06/189321612/nsa-reportedly-mines-servers-of-u-s-internet-firms-for-data (accessed 7/2/2013).
(2) "Startup sees boost in business following news of NSA surveillance - Washington Business Journal." Last modified 07/03/2013 04:06:02. http://www.bizjournals.com/washington/blog/techflash/2013/06/startup-sees-boost-in-business.html (accessed 7/2/2013).
(3) "Azimuth Security: Attacking Crypto Phones: Weaknesses in ZRTPCPP." Last modified 07/02/2013 13:28:12. http://blog.azimuthsecurity.com/2013/06/attacking-crypto-phones-weaknesses-in.html (accessed 7/2/2013).
(4) "Impact of ZRTP library critical security vulnerabilities · Issue #5 · SilentCircle/silent-phone-base · GitHub." Last modified 07/03/2013 04:38:41. https://github.com/SilentCircle/silent-phone-base/issues/5#issuecomment-20232374 (accessed 7/2/2013).
(5) " Microsoft’s Many Eyeballs and the Security Development Lifecycle - Thinking About Security - Site Home - MSDN Blogs ." Last modified 07/03/2013 04:52:27. https://blogs.msdn.com/b/shawnhernan/archive/2010/02/13/microsoft-s-many-eyeballs-and-the-security-development-lifecycle.aspx?Redirected=true (accessed 7/2/2013).
(6) "What Happened With ZRTP This Week | Silent Circle Blog." Last modified 07/03/2013 05:10:20. http://silentcircle.wordpress.com/2013/06/29/what-happened-with-zrtp-this-week/ (accessed 7/2/2013).
(3) "Azimuth Security: Attacking Crypto Phones: Weaknesses in ZRTPCPP." Last modified 07/02/2013 13:28:12. http://blog.azimuthsecurity.com/2013/06/attacking-crypto-phones-weaknesses-in.html (accessed 7/2/2013).
(4) "Impact of ZRTP library critical security vulnerabilities · Issue #5 · SilentCircle/silent-phone-base · GitHub." Last modified 07/03/2013 04:38:41. https://github.com/SilentCircle/silent-phone-base/issues/5#issuecomment-20232374 (accessed 7/2/2013).
(5) " Microsoft’s Many Eyeballs and the Security Development Lifecycle - Thinking About Security - Site Home - MSDN Blogs ." Last modified 07/03/2013 04:52:27. https://blogs.msdn.com/b/shawnhernan/archive/2010/02/13/microsoft-s-many-eyeballs-and-the-security-development-lifecycle.aspx?Redirected=true (accessed 7/2/2013).
(6) "What Happened With ZRTP This Week | Silent Circle Blog." Last modified 07/03/2013 05:10:20. http://silentcircle.wordpress.com/2013/06/29/what-happened-with-zrtp-this-week/ (accessed 7/2/2013).
Subscribe to:
Posts (Atom)