Bug #2056
SECURITY: Gibberbot sends encrypted messages despite fingerprints not matching.
| Status: | Closed | Start date: | 10/10/2013 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | devrandom | % Done: | 0% | |
| Category: | - | |||
| Target version: | v14 - Armadillo's Agram | |||
| Component: |
Description
Alice & Bob both use:
Gibberbot version 0.0.11-RC5
obtained from https://guardianproject.info/releases/Gibberbot-0.0.11-RC5.apk
cryptographic signatures verified
running on Cyanogenmod 10.1.3 stable
Alice & Bob both install Gibberbot, input their username/password for the dukgo.com XMPP service, and mutually verify each other's cryptographic fingerprint in person and set it as verified in Gibberbot.
Alice then switches off her device, and sets up Gibberbot on a different device. When she starts Gibberbot, she receives a readable message from Bob, in the format "[resent] Whatever was the last message sent around the time Alice switched off her previous device".
This is a massive issue since it means that Bob's Gibberbot sent a message even though Alice's new device fingerprint was different from the verified one.
I can reproduce this 100% of the time.
I did not test on Chatsecure beta.
History
#1 Updated by devrandom over 4 years ago
- Assignee set to devrandom
- Priority changed from Normal to High
- Target version set to v13 - October Oooya
Need to detect trust level lowering and not resend pending messages.
Proposed trust level lowering definition:
- If the new fingerprint is unverified while the old one was verified
- If the new fingerprint is unverified and different and the old one was unverified
#2 Updated by devrandom over 4 years ago
- Subject changed from Gibberbot sends encrypted messages despite fingerprints not matching. to SECURITY: Gibberbot sends encrypted messages despite fingerprints not matching.
#3 Updated by n8fr8 about 4 years ago
- Target version changed from v13 - October Oooya to v14 - Armadillo's Agram
#4 Updated by hans almost 3 years ago
- Status changed from New to Resolved
My guess that this is because of this bug, which is now fixed:
https://github.com/otr4j/otr4j/pull/6
#5 Updated by n8fr8 over 2 years ago
- Status changed from Resolved to Closed