Untitled

Signal - Deleted, but not forgotten =================================== The latest version of this advisory is available at: https://sintonen.fi/advisories/signal-deleted-but-not-forgotten.txt Description ----------- Signal client uses SQLcipher database to store conversation messages. Since SQLcipher is essentially SQLite with encryption, it inherits SQLite features. To update the database, SQLite (and consequently SQLcipher) uses Write-Ahead Logging. All transactions are written to a Write-Ahead Log file, which is then merged to the main database file when a certain number of pages are written to the log file, the database is manually checkpointed, or the database file is reopened. This results in an unexpected situation when messages are deleted in Signal, either manually or by a timed deletion. The deletions from the database are recorded to the Write-Ahead Log file, but they are not actually deleted from the database file until the Write-Ahead Log is committed back to the main database. By default, the Write-Ahead Log has a threshold size of 1000 pages. Depending on how busy your Signal app is, this transaction limit could take several days to reach. This means that the messages deleted in Signal will linger on disk far longer than expected. The database file with the supposedly deleted messages can easily end up being backed up to Time Machine backups, adding unexpected data persistence. Impact ------ Many people and organizations are using disappearing messages to ensure that no trace of messages remains after a certain timeout. It is also fair to expect a message to disappear from disk as soon as it disappears from the UI. Due to this flaw, the messages may be recoverable from disk for far longer than expected, up to multiple days, or even weeks for low-volume messaging. Since Signal message database is included in macOS Time Machine backups, the supposedly deleted messages can remain recoverable from such backups for years. The message database file is encrypted. This lessens the impact of this vulnerability significantly. However, this vulnerability may become significant if mobile device acquisition (or other kind of device forensics) is a threat the Signal user tries to defend against and if disappearing messages are employed in attempt to protect against such recovery. Restrictions ------------ This vulnerability is mitigated by several factors: 1. The database is encrypted. To extract any deleted messages, the attacker will have to defeat the encryption. This requires capabilities and expertise. 2. Active Signal use will reach the Write-Ahead log page limit fast, leading to merging of log fairly regularly. 3. Signal app restart will commit the Write-Ahead Log, deleting the messages. Proof-of-Concept ---------------- This Proof-of-Concept demonstrates the issue with Signal macOS desktop app: 1. Grab and build https://github.com/fjh658/signal-decryption-tool 2. Utilize signal-decryption-tool to obtain the encryption key with: $ target/release/SignalDecryption -p 3. Send a test message from external account to your Signal. Use some content you can later search for, such as "KENSENTME". 4. Delete the message in your Signal desktop app. 5. Copy the Signal database separating it from the Write-Ahead Log file: $ cp ~/"Library/Application Support/Signal/sql/db.sqlite" . 6. Use sqlcipher to extract the now supposedly deleted message: $ sqlcipher db.sqlite sqlite> PRAGMA key = "x'hexkeyhere'"; sqlite> select * from messages where body like '%KENSENTME%'; Recommendations to vendor ------------------------- Modify Signal application to perform manual commit on message deletion to ensure that delete messages won't stay on disk unexpectedly. The strategy could employ a delay timeout of a short period to avoid excessive write operations on multiple deletions. On macOS, consider excluding the message database from backups by using com.apple.metadata:com_apple_backup_excludeItem attribute. End user mitigation ------------------- 1. After deleting highly sensitive information, restart Signal app to force a Write-Ahead Log commit. 2. With macOS, consider excluding ~/Library/Application Support/Signal/sql from Time Machine backups: $ sudo tmutil addexclusion -p ~/"Library/Application Support/Signal/sql" Note: You may be requested to grant Full Disk Access privileges to the Terminal application - if you do so, you can remove the privilege after adding the exclusion. 3. For high security communications, avoid linking your mobile Signal to the desktop Signal client. Affected Applications --------------------- - Signal Desktop application is affected (macOS app tested). - Signal Android application is likely affected. - Signal iOS application does not appear to be affected due to custom checkpointing strategy. However, I did not test this is in detail. Timeline -------- 2025-11-23 discovered the vulnerability. 2025-11-23 sent report to security@signal.org - no acknowledgement received. 2025-11-25 sent report to NCSC-FI to inform finnish stakeholders. 2026-02-27 resent report to security@signal.org asking for acknowledgement of receipt - no response. 2026-04-23 requested help on reaching Signal security team on Mastodon - several individuals offered help and apparently forwarded my message to people in contact with the team. 2026-05-22 macOS application confirmed to be still vulnerable - zero communication from Signal has been received. 2026-05-22 public disclosure after 180 days.