Last night TokBox released patches to the OpenTok iOS and Android SDKs to resolve a recently identified OpenSSL vulnerability that affects the majority of web service providers.
‘An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server.’
It is important to note that this is a different security advisory from the “Heartbleed” issue of April 2014. By the time version 2.2.0 of the OpenTok Android and iOS SDKs were released, we had already updated clients with the patch released on the same day as the announcement.
Who is Affected?
This affects OpenSSL 1.0.1 SSL/TLS users (client and/or server) and is solved by upgrading to OpenSSL 1.0.1h. Both of the OpenTok Android and iOS SDKs were affected by this issue in version 2.2.0.
Addressing The Issue
We have rebuilt the Android and iOS SDKs 2.2.0 branches with updated dependencies packages, including relevant updates to OpenSSL to provide adequate security. For iOS, the updated library was built externally and linked with the SDK. For Android, the solution relies on a dependency injection of OpenSSL that is maintained by the Chromium project, as it is declared as a dependency for WebRTC.
How YOU fix this:
Recompile your mobile application with the newly released version 2.2.1 of the OpenTok iOS and Android SDKs. Resubmit your application to the App Store or Google Play Store.
Complications for Android
Google Play is notifying developers about potentially insecure apps that have bundled older versions of OpenSSL. Apart from exploit testing and binary analysis, the only way to check for the version of OpenSSL is to inspect the binary and extract readable strings, searching for OpenSSL (referred to as the “strings check”). While the chromium-maintained OpenSSL has updated security fixes patched in, the version string header — where the aforementioned strings check results are derived — is out of date, and does *not* have a declaration of 1.0.1h. The Chromium team has been made aware of the issue, and are working on a more sustainable approach to importing commits from the OpenSSL project.
Implications for Play Store.
At present, the complications above mean that the release candidate for Android SDK 2.2.1 is secure in the sense that no known vulnerabilities are present as documented by our third-party providers and can be safely submitted to the Google Play Store. Just be forewarned, the strings check for the embedded OpenSSL version produces an inaccurate result.