CVE-2024-45193
📋 TL;DR
This vulnerability in Matrix libolm allows attackers to create different but valid signatures for the same message due to insufficient Ed25519 signature validation. This affects applications using libolm for cryptographic operations, particularly those implementing the Olm protocol for end-to-end encryption. Only unsupported products are affected according to maintainers.
💻 Affected Systems
- Matrix libolm library
- Applications using libolm for Olm protocol implementation
📦 What is this software?
Olm by Matrix
⚠️ Risk & Real-World Impact
Worst Case
Signature malleability could enable replay attacks, message tampering, or protocol-level attacks in systems that rely on unique signatures for message validation or non-repudiation.
Likely Case
Limited practical impact in most deployments since libolm is typically used in Matrix clients where signature malleability doesn't directly compromise encryption, but could affect custom implementations with strict signature uniqueness requirements.
If Mitigated
Minimal impact if applications don't rely on signature uniqueness or have additional validation layers; Matrix protocol implementations generally handle this gracefully.
🎯 Exploit Status
Exploitation requires understanding of Ed25519 signature scheme and ability to manipulate cryptographic operations; technical details published in security blog posts.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: Fixed in commit 6d4b5b07887821a95b144091c8497d09d377f985
Vendor Advisory: https://gitlab.matrix.org/matrix-org/olm/
Restart Required: Yes
Instructions:
1. Update libolm to version with commit 6d4b5b07887821a95b144091c8497d09d377f985 or later. 2. Rebuild applications using libolm. 3. Restart affected services. 4. Consider migrating to vodozemac library as recommended by maintainers.
🔧 Temporary Workarounds
Implement signature validation wrapper
allAdd additional validation in application code to ensure S < n for Ed25519 signatures
Disable vulnerable functionality
allIf possible, disable or work around signature verification that relies on libolm's implementation
🧯 If You Can't Patch
- Isolate systems using vulnerable libolm versions from untrusted networks
- Implement additional monitoring for unusual cryptographic operations or signature validation failures
🔍 How to Verify
Check if Vulnerable:
Check libolm version: if using version 3.2.16 or earlier and commit older than 6d4b5b07887821a95b144091c8497d09d377f985Check Version:
Check build configuration or package manager for libolm version; for source builds, examine git history for the fix commitVerify Fix Applied:
Verify libolm includes commit 6d4b5b07887821a95b144091c8497d09d377f985 or check version is newer than 3.2.16📡 Detection & Monitoring
Log Indicators:
- Multiple valid signatures for same message
- Signature validation failures
- Unexpected cryptographic errors
Network Indicators:
- Unusual patterns in encrypted message exchanges
- Repeated messages with different signatures
SIEM Query:
Search for cryptographic operation errors or multiple signature validations for identical content