Hi Zoom Support Team,
Subject - FirstNet Compliance Failures: Security Flags for SharedPreferences, Legacy Crypto (SHA-1), and WebView Debugging in Android Meeting SDK v6.5.1.31081
We prepared our production application for a highly secure deployment on the FirstNet Network. Our application integrates the Android Meeting SDK version 6.5.1.31081.
Following a mandatory automated and static security assessment by FirstNet, our build was flagged with three compliance issues arising entirely within the core binary modules of the Zoom SDK.
We require your guidance, verification of a programmatic workaround, and information on whether these blocks will be addressed in an upcoming release cycle.
Issue 1: Insecure Storage (World-Readable SharedPreferences)
- Finding: The security scan flagged potential utilisation of deprecated file permission MODE_WORLD_READABLE / MODE_WORLD_WRITEABLE within ZoomApplication.java or linked internal configuration components.
- Question: Is this block maintaining active legacy hooks, or is this dead code lingering within the mobilertc.aar package? How can we guarantee to the auditors that no application data is exposed to third-party app packages at runtime?
Issue 2: Use of Broken Cryptographic Algorithms (SHA-1 / MD5)
- Finding: The static analysis engine detected hardcoded cryptographic string matching signatures for “SHA-1” and “MD5” within core compiled packages (us.zoom. / com.zipow.).
- Question: We assume these signatures exist for backward-compatibility handshakes with legacy telepresence infrastructure or internal non-cryptographic checksums. Can you officially confirm that real-time streaming components (video/audio data packets) natively use AES-256-GCM transport encryption exclusively in this version, isolating the flagged algorithms from the user attack surface?
Issue 3: Remote WebView Debugging Enabled
- Finding: The SDK explicitly invokes WebView.setWebContentsDebuggingEnabled(true) in production release binaries, presenting an arbitrary code execution risk if an attacker bridges physical access to the device.
- Reference: This exact issue has been brought up on the Zoom Developer Forum: Ticket - WebView.setWebContentsDebuggingEnabled(true) found in release build — Zoom Meeting SDK Android 6.3.10
- Workaround Check: To satisfy our security gate immediately, we intend to force-disable this flag dynamically directly after the SDK initialization completes:
override fun onZoomSDKInitializeResult(errorCode: Int, internalErrorCode: Int) {
// Force override the flag globally to pass the FirstNet security scan
android.webkit.WebView.setWebContentsDebuggingEnabled(false)
}
Question: Is this specific initialisation override fully compatible with the SDK’s lifecycle, or will it disrupt internal components or web-based UI fragments during an active meeting session?
Summary & Resolution Paths
We have audited Android Zoom Meeting SDK release change logs through version 7.0.5 and have found no mentions of these specific security vulnerabilities or hardening implementations.
Does Zoom provide a secure-baseline configuration API to switch off debugging behaviours globally, or are there internal patch targets scheduled to clear these legacy code blocks in a future SDK update?
As this is currently a hard blocker for our FirstNet network authorization, please look into this ASAP.
Which Android Meeting SDK version?
Android Meeting SDK v6.5.1.31081
Thanks!