AD5015: DoNotStaticallyLinkOpenSSL¶

Summary¶

Description¶

Statically linking OpenSSL means your application includes the cryptographic library directly in the binary. While this can simplify deployment, it creates a significant security maintenance burden.

Why This Matters¶

Cryptographic libraries sit at the foundation of application security—they protect data in transit, authenticate users, and safeguard sensitive information. When these libraries have vulnerabilities, the consequences can be catastrophic. OpenSSL, despite being the most widely-used TLS implementation, has a significant history of critical security flaws.

The Vulnerability History¶

OpenSSL vulnerabilities have caused some of the most widespread security incidents in internet history:

OpenSSL averages 15-25 CVEs per year, with several rated Critical or High severity. This is a fundamental reality of maintaining complex cryptographic code.

The Static Linking Problem¶

When you statically link OpenSSL, you embed a specific version permanently into your binary:

1. Frozen Vulnerabilities: Your application ships with whatever bugs existed in OpenSSL at compile time. A vulnerability discovered tomorrow requires you to rebuild, retest, redistribute, and convince users to upgrade.

2. Update Lag: The median time from CVE disclosure to application update is often weeks or months for statically-linked software, while system library updates deploy in days.

3. Invisible Risk: Users and administrators have no visibility into which OpenSSL version is embedded. They cannot audit their exposure or prioritize updates.

4. Compliance Complications: Security auditors and automated scanners may fail to detect vulnerable embedded libraries, giving false assurance.

Real-World Consequences¶

After Heartbleed, organizations discovered they had hundreds of applications with statically-linked OpenSSL, each requiring individual remediation. Some applications were never updated because vendors had gone out of business or abandoned the software. These zombie applications remained vulnerable for years.

The Dynamic Linking Advantage¶

Dynamic linking to system OpenSSL provides critical benefits:

• Automatic Updates: System package managers (apt, brew, Windows Update) patch the library; your application benefits immediately without any action on your part.

• Single Point of Update: One system update fixes all applications using that library.

• Transparency: ldd or otool clearly shows which libraries an application uses; administrators can audit their exposure.

• Smaller Binaries: You don't ship redundant copies of OpenSSL, reducing download sizes and disk usage.

Performance Considerations¶

Dynamic linking has negligible runtime overhead (typically <0.1% for function call indirection). There is no performance justification for static linking of OpenSSL.

Option 1: Use Dynamic Linking (Recommended)¶

Link against the system OpenSSL dynamically:

# Use pkg-config for dynamic linking
clang $(pkg-config --cflags --libs openssl) your_code.c

Option 2: Use Apple's Security Framework¶

For macOS/iOS, prefer Apple's built-in cryptographic framework:

#include <Security/Security.h>
#include <CommonCrypto/CommonCrypto.h>

// Use CommonCrypto for hashing, encryption, etc.

Apple's Security framework: - Is maintained as part of the OS - Receives automatic security updates - Integrates with Keychain and other system security features - Is required for App Store apps in many cases

Option 3: Use LibreSSL¶

macOS ships with LibreSSL (an OpenSSL fork) which is dynamically linked:

clang -lssl -lcrypto your_code.c

Detection¶

This rule detects static OpenSSL linkage by checking for multiple OpenSSL-specific symbols in the binary, such as: - OPENSSL_init_ssl - SSL_CTX_new - EVP_EncryptInit - AES_encrypt

References¶

• OpenSSL Security Advisories
• Apple CommonCrypto Reference
• CWE-1104: Use of Unmaintained Third Party Components