Images from another user displayed in message #10247
Comments
|
Updated with info from party B. |
|
Can you get me the timestamp of the sent message? To do so, you can long press a message -> click the info (i) button -> long press the sent timestamp to copy it to your clipboard. Can you find out if those images are from another conversation B has? |
|
Thanks for getting back to me. The timestamp of the sent message is 4 Dec 2020, 12:38:06 NZDT. No, the images did not arrive in another conversation the B has. |
|
Just wanted to chime in and say I'm experiencing this same issue too and I have been for months now (even through a couple of upgrades). I've noticed that the Linux client does not exhibit this behavior but if this happens on the Android app, the mixed up images can be seen in the Linux client. My device is a Xiaomi Redmi Note 4 running LineageOS 15.1-20190417-NIGHTLY-mido (Android version 8.1.0) with Signal 4.78.5. This has happened with several contacts running different phones. I'll try to gather that info if it's helpful. |
|
I just experienced it too on an OnePlus 8 device running Signal 5.2.3 on Oxygen OS 11.0.2.2.IN21AA. The photo that got attached but shouldn't was from a conversation 3 hours earlier which already got wiped out from my history on Android (but was still present in the desktop app and on the other party's devices): Sent | Friday, January 22, 2021 12:47 PM (1611316029448) It got attached at: Sent | Friday, January 22, 2021 4:18 PM (1611328729188) Debug logs are here: https://debuglogs.org/133f5f4df25324d0fdbeeebedd56a1ff227488d83ed6c47773fe584be81fde8a I hope someone will find time to look at this soon, as this is a serious issue for conversation privacy. It effectively renders sending images confidentially impossible. |
|
Sorry for the bump but I wanted to say this is happening consistently for me now. Anytime I send images or links (with a preview), other images or images from link previews are sent to the other party as well (regardless if they were privy to the previous images). It's gotten to the point where I send the images to my desktop via 'note to self' (which exhibits the same behavior) and then I download the image and send it along to the correct person. The desktop (linux) client does not have this issue. |
|
I still have this issue after multiple updates and it's started happening with MMS messages as well either to a single individual or a group. It doesn't matter if the group is composed of all signal users, all MMS numbers, or a mix of the two. |
|
@cmhobbs Can you please post a log taken after you experience the issue? |
|
Sure! What's the process for obtaining the logs? I can send a couple of messages anytime as this happens regularly. |
|
Settings > Help > Debug log > Submit, then paste the link here. Thanks! |
|
This first log is after I sent a single image to the "Note to Self" contact. It ended up sending three images unrelated to previous messages in that chat along with the one I intended to send. https://debuglogs.org/e0b22917d34658aa760cd09906a4c918ea067259753fb46fdff8dcd5bd962457 This second log is after I sent an MMS message to a group. The group consisted of myself, one person who doesn't have signal, and one person that does. I only sent text and didn't attach any images and it attached a single image. I'm not even sure if the image it attached is from any of my other messages. I think it's only in my phone's gallery. https://debuglogs.org/26b78bca1f97e47871797fab9987c97afa981ece7f66b0ceadea44056d78b5ae I'm using the same phone and ROM I mentioned in my previous comments. |
|
i have a contact who experiences this (Android 11, Oneplus 7). not only is his Signal randomly sending images to me that he didn't intend to, even without initiating the addition of any attachments on the GUI... he even sees one of my messages displayed on his side with a random image attached to it, as if i have sent that image to him, even though that image is not even present on my phone. it seems to be happening only with images that have been received by his signal app in the past. |
|
I've also recently had a probably unrelated issue where my mic was still audible to the other party after I hung up the call. I'm going to migrate off of Signal because I simply don't trust my copy of the client at the moment. I'll leave it installed until the end of the week while I let folks know other ways to contact me. If you need more debug logs for this, I can generate them most any time until then. I'm able to reliably duplicate this issue. |
Could you provide a debug log after this occurs, and let us know which UX path you took to hang up the call? |
|
Sure. I'll make an attempt to reproduce it this evening. Should a separate issue be created for it given that it's (maybe) not related to the image issue? |
|
@cmhobbs If you don't mind that would be preferred. |
|
This is crazy. This bug should be the number 1 priority for Signal right now and yet all they do is ask for logs and make enhancements that aren't anywhere near as important as fixing this. This is a bug that should kill Signal, honestly. |
|
Hi there, sorry, this issue was fixed in 5.17 (which hit 100% production on 7/21). There was another issue tracking this and it looks like I forgot to close this one. For some background, this bug came about as a rare intersection of some database properties and a separate bug. The TL;DR is that if someone had conversation trimming on, it could create a rare situation where a database ID was re-used in a way that could result in this behavior. It was very difficult to track down, with earlier phases involving getting additional logging into builds. Once we had some more information, it did in fact become our top priority, a fix was made, and we got it out as quickly and as safely as possible. The fix itself should make it so that database issues like the one that caused this bug can't happen again. |
|
Could you provide a link to the bug fix commit / MR? |
A link to the other issue would be nice as well. |
|
The crux of the issue was around SQLite auto-incrementing IDs. These are the commits that added them to a few tables that needed them. |
|
Can you explain exactly how auto-incrementing IDs were the crux here? Were they overflow-wrapping or did the tables forget to actually use them? |
|
For such a significant bug, we hardly have any detailed explanation of what exactly went wrong and what the general lessons are. I wouldn't be saying this if this issue wasn't already closed. A full postmortem will be nice at some point. |
|
@impredicative , it's hard to know what's going on in there but I'd say give them a chance to breathe. Perhaps they've been burning the moonlight oil trying to fix this issue and they need a breather before doing PR. |
The commit messages don't have an issue id on them, and I find it hard to find out if they were linked to a pull request from github's interface. There might not be a need for a postmortem if they were already linked to an issue that explains the bug and the fix, with the linked pull request containing these commits. I'm guessing there's a private issue tracker for this stuff |
|
From the linked SQLIte page in this comment:
The commits add the |
|
I'm very relieved this has been fixed. Let's hope nothing this crazy ever pops up again! Thank you, Greyson, for clearing things up.
Sent from ProtonMail mobile
…-------- Original Message --------
On Jul 25, 2021, 2:24 PM, Greyson Parrelli wrote:
Hi there, sorry, this issue was fixed in 5.17 (which hit 100% production on 7/21). There was another issue tracking this and it looks like I forgot to close this one.
For some background, this bug came about as a rare intersection of some database properties and a separate bug. The TL;DR is that if someone had conversation trimming on, it could create a rare situation where a database ID was re-used in a way that could result in this behavior. It was very difficult to track down, with earlier phases involving getting additional logging into builds. Once we had some more information, it did in fact become our top priority, a fix was made, and we got it out as quickly and as safely as possible. The fix itself should make it so that database issues like the one that caused this bug can't happen again.
—
You are receiving this because you commented.
Reply to this email directly, [view it on GitHub](#10247 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AG56ID5FHRZWAUXXTN5BGZTTZRJGPANCNFSM4UM3AADA).
|
|
Why aren't these types of objects encrypted with the current (group) chat's keys? Why should being accidentally slipped another chat's ID by mistake allow someone to resolve it to an image or a url to an image? Bit confused by this. |
|
Should Signal responsibly create a CVE for this? I only see this: https://www.cvedetails.com/vulnerability-list/vendor_id-17912/Signal.html |
|
I'm afraid similar bug still exists. I'm in a group chat with 5 people. (4 of us are admin). Android Signal Version: 5.45.6 He's not a technical person I couldn't get any more information like logs etc. |
Considering this report, is Signal even safe to use? It is not just the matter of such a bug. Signal looks to lack basic cryptographic safeguards to ensure that a message can only be decrypted by the intended recipients. In July 2021, @saflendesk asked the following, but there was no response from Signal:
Personally, I have stopped asking people to install Signal, referring them to Session or Simplex, etc. instead. |
|
@exithacker It's really hard to do anything in this situation without logs or additional details. These are the questions that come to mind:
In general, I've often seen confusion arise when people have bad data in their system contacts. They have numbers or names mixed up, and they think a message is going to someone else. I can't say if that's what happened here though. But this is the first report of such a thing that we've had since this issue was closed, and I can't think of a way it would happen, so it'd be good to double check.
Signal encrypts attachments with a key that is sent via the Signal protocol. No one can decrypt it unless you give them the key. But you could imagine a theoretical bug where the client sends the key to the wrong set of recipients. I'm not saying that's what's happening here -- as stated, without more debugging info it's hard to do more with the report. But I want to clarify that attachments can't be read just by knowing the URL or something. You need a key from the sender. |
|
@greyson-signal Out of curiosity, is there any risk of a hash collision causing a message to be sent to an incorrect recipient? This could be in the application or in its database or via a cryptography function. I hope and assume the answer is no, but if there were 100 million users, each having 100 contacts, then maybe in some situations a 64-bit hash can be insufficient. |
Yes, a chat window opened to that contact, just like sending the image directly to him for the first time (because they've no chats before).
He has not talk to receiving (wrong contact) side about this issue, so he don't know exactly what it looks like.
Signal group.
Friend can see himself as one of the admins. (he is really one of the admins)
We have not noticed any overlap in information. Phone numbers, names, nothing was same. Even the names, the surnames' initials was different.
Yes, of course. One thing I've noticed maybe unusual is my friend is a medical doctor, he has lots of patients and there are 866 people on his contact list.
|
|
@exithacker When this happened, was your friend sharing media into the app (like sharing from Google Photos into Signal), or using the camera button on the Signal chat list screen? Or maybe forwarding media? These screens allow you to select multiple contacts to send media to. I wonder if there's either a bug on that screen, or if this contact sits in a location where it might be easy to accidentally tap them (maybe they're underneath the 'next' button or next to the group in search results or something). These are the only flows I can think of where we even really have the possibility of sending to distinct groups of people. So if you could confirm that with your friend, that will help us narrow the problem space down.
No, hashes don't come into play here. Messages get sent to a UUID, which are ensured to be unique. |
I've asked to friend more details again, and he said using "Samsung Gallery" he selected share via Signal app. Interestingly, after deleting and re-adding that person solved the issue for him. Maybe there was somehow a db corruption happened in some point but this is not still easy as far as i can think of, and should not be.
|
|
@exithacker We list the selected recipients at the bottom of the screen as you select them. Do you recall if your friend looked at that list and verified there was only one contact? If the group name is long, it could be that the other contact name was scrolled off to the side. That list represents the same list we send to the next screen, so knowing if the user was in there will narrow our search space. |
He checked the list and he's sure there was only one target because after the first incident to confirm he repeated sending image a few times. In all tries on that moment image also sent to that wrong contact too. |
|
Ok, thank you 👍 |
|
This just happened to me. It happened once before and I thought it was something I did. This morning it happened again and I'm positive I did not do it. Yesterday (Sept 7th, 11:10AM), I sent ("shared") a photo via 'Google Photos' app on my Android phone, to my son on Signal (User-A). He responded with a comment at 11:11AM. This morning, I used Signal to try to voice-call User-A. He didn't answer. I aborted the call. A few moments later, I received a Signal message from a friend, User-B, referring to the photo. I did not send the photo to User-B. In fact, my previous chat session with User-B was on Sept 1st. I checked my paste-buffer and the photo was not in the paste buffer, nor was there in fact anything in the paste buffer. This Android device is a new phone (Pixel-7) that I got on Sept 7th and thus, it should be the latest version of Signal and latest version of Android. This is a chilling bug. If Signal is leaking data between chats, it makes me cringe. |
|
what kind of architecture can result in such a bug? it makes one wonder, maybe it's a bug in a backdoor? |
|
I've looked through your log. I see a message sent on 9/7 @ 11:10:30am. It was an image you shared into the app and it was sent to a single person. It was not sent to anyone else. I see you tried to call the person you sent a message to on 9/8 @9:03:32am. So that all seems to line up as you said. Sounds like User-A. And then the next message you receive after the call is from a different person at 9:04:26am. So that lines up too. Sounds like our User-B. Before User-B sent you a message, it looks like you send User-B a message at 9:03:53am, so about 20 seconds after your attempted call with User-A. Specifically, it looks like you had opened the photo in your chat with User-A and then forwarded the message to User-B. Does that series of events sound plausible? |
|
On Sep 8, 2023, at 11:59 AM, Greyson Parrelli ***@***.***> wrote:
@hpeyerl
I've looked through your log. I see a message sent on 9/7 @ 11:10:30am. It was an image you shared into the app and it was sent to a single person. It was not sent to anyone else.
I see you tried to call the person you sent a message to on 9/8 @9:03:32am. So that all seems to line up as you said. Sounds like User-A.
And then the next message you receive after the call is from a different person at 9:04:26am. So that lines up too. Sounds like our User-B.
The above is all plausible and likely correct.
Before User-B sent you a message, it looks like you send User-B a message at 9:03:53am, so about 20 seconds after your attempted call with User-A. Specifically, it looks like you had opened the photo in your chat with User-A and then forwarded the message to User-B.
This does not seem plausible.
When my call to User-A was not answered, I aborted the call (red icon), and closed my phone and started walking to my garage. The phone was in my pocket.
Does that series of events sound plausible?
I’m not even sure if it’s plausible to “butt dial” the forwarding of the photo and 20 seconds after my attempted call, I was well and truly entrenched in my garage work.
Early onset dementia might be my next hypothesis. :-)
Anyway, to be more serious, I’m 99.9% positive I did not forward the photo. I just tried to replicate the steps needed to forward the photo and was surprised to see “My Story” as one of the options. I’m not sure if I’ve ever forwarded a photo but I also don’t think I’ve seen “My Story” anywhere before so I’m pretty sure I would have noted it then as well if I’d done it.
|
|
I should add that the outbound message to User-B containing the photo does appear in my chat history with User-B. I was surprised to see it there when User-B responded to me at 9:04:26. |
Ok good! I forgot to ask that, but that makes sense because the logs show a message being sent to them. I'll paste the log lines here so you can see the story that I see: Hanging up with User-A: Opening a photo (ZoomingImageView is the fullscreen photo view): This log is less obvious, but this log is printed when we check for identity key mismatches as you select people in the "forwarding" bottom sheet: And then here's the message send. With all that together, it certainly feels possible that you may have forgotten to lock your phone when you put it in your pocket? Like, there's 20 seconds in between the photo open and the message being forwarded. It's also worth noting that the forward button is in the bottom right of the screen, which is also where the send button is on the forwarding bottom sheet. Which is to say I could imagine that the bottom right corner of the screen rubbed on the inside of your pocket a couple times (possibly very rapidly in sequence), which could feasibly open the forward sheet, select someone, and then hit the send button, which would all be physically in the same area of the screen. I know this is weird, but I'm just trying to reconcile your experience with what I see in the logs. |
|
I mean, it's definitely weird and seems far-fetched. I have a habit of putting my phone in my pocket with the screen facing my leg instead of facing out to protect the screen while I'm working on sharp things that might impact my phone. That would mean it would be my thumb doing the selecting, or my thigh perhaps. I distinctly remember the bling of my text notification at 9:04 from User-B responding. I was fighting with the fingerprint sensor on my new phone because my hands were dirty and I had to use my alternate unlock method. So that suggests the phone had become locked before I pulled it out of my pocket. It feels unusual for me to think I didn't lock the phone before putting it in my pocket. Then even more unusual to think my thigh pressed all the right locations, through the fabric in the pocket of my carhartts and then locked itself between 9:03:52 and 9:04:26. From the log snippets above, it appears the "Sending media message to RecipientId::158" happened 55ms before the "No identity key mismatches". Does that mean my thigh selected a recipient after it sent the message to that recipient or is that just a result of threading in the logging subsystem? Regardless, I can't offer any more information or insight so I guess there's no sense pursuing this. Thanks. |
The process to fetch the mismatches is asynchronous and doesn't block send, it's an optimization we try to do. It implies that the contact was selected and then send was pressed in rapid succession.
I guess the point of me describing the button locations on screen was me trying to say that you wouldn't have to hit a bunch of distinct locations on the screen. There would only have to be a few rapid taps registered in the same location in the bottom right corner (you can literally tap forward on a photo, tap again in the same spot (which will select a contact), and then tap again in the same spot to send the photo). Again, not trying to be dismissive, I'm just trying to say that there are unambiguous events in the log that indicate a photo was opened and the forward sheet was opened, all while you believe the phone was in your pocket. And I feel like given how the buttons are laid out, it doesn't seem out of the question that your phone may have triggered taps through your packet in the bottom right corner. |
For what it's worth, Signal has an app screen lock feature too in its settings, but this feature leaves a lot to be desired. It is currently so messed up that I would never use it. For one, there is no obvious way to set a PIN to unlock it. To date, my password manager lists that I already set three distinct PINs in Signal with different labels, but none of them allow me to unlock Signal's screen lock. If the fingerprint reader stops working or if I am wearing gloves, I will not be able to unlock it. Secondly, there is no way to configure it to auto-lock Signal immediately once the app is no longer in focus. It has to wait for at least 1 minute before it locks; why? |
I understand. I think we're on the same page. 30+ years in embedded firmware and I've seen bugs reported that the logs and the code say are simply impossible. We all want to find bugs in our code if they exist. As you say, the logs would seem to be unambiguous and thus I have to conclude that I somehow did this. As inconceivable as it seems. |
Bug description
Standard conversation between two users (let's call them party A and party B). Party A shares a gif (from built in gif search). Party B receives the gif, but also some other images, which appear to be from another user (party A has searched their phone and does not remember the images in question). Best case the images are from another contact of B and messages got crossed, worst case they are from an unknown party, who's data has now been leaked. Luckily in this case they were not sensitive.
Steps to reproduce
Actual result: Images which were not sent by party A appear in party B's conversation
Expected result: Images from different conversations/users shouldn't leak
Screenshots
Party A:
Party B:
Device info
Party A:
Device: Samsung A30
Android version: 10 (seems somewhat non-specific, but that's what the UI shows, happy to provide more info on request)
Signal version: 4.78.5
Party B:
Device: Motorola Moto G7 Power
Android version: 10
Signal version: 4.78.5
Link to debug log
Party A: https://debuglogs.org/ff7236bae38ec64dbe4cd2b57a22c32ea45c6a5025e59cc19447b9eca4e9fe66 (was taken some time after the issue occurred, next time I'll be quicker)
Party B: https://debuglogs.org/02d5cea4bfd6d6c046c1e6d2cfca26093cf4242ad99483bb3fbdff52844a09a4 (also taken some time after the issue occurred)
I'm still awaiting device info and debug logs from Party B, I'll update when I have them. EDIT: now complete.
The text was updated successfully, but these errors were encountered: