Potential "DOS" (android app, not server) vulnerability

primeos commented 7 years ago

I have:

[x] searched open and closed issues for duplicates
[x] read https://github.com/WhisperSystems/Signal-Android/wiki/Submitting-useful-bug-reports

Bug description

Sending huge messages (the limit might somewhere around 2096632 bytes) effectively renders the Android app of the receiver unusable (the app will crash immediately after launching). This could be potentially abused for a "DOS" attack. I assume for a normal user the only way to recover from that would be to delete all the app data (or reinstall the app). That would result in loosing the complete chat log (without a backup) and having to generate a new key. Either way abusing this will cause unnecessary trouble for the receiver.

Steps to reproduce

Disclaimer: Don't try this with your "real" app (or at least not without a backup) as this will probably permanently disable (i.e. crash) your app! There might be better ways to reproduce this.

http://www.loremipsum.de/
Generate 1000000 words
Paste the output inside the "Signal Desktop" extension
Wait a few minutes (takes some time to sync)
The Android app of the receiver (and your own app!) will crash
You won't be able to use the app anymore, since it will instantly crash as soon as you try to launch it!

GIF:

crash

Device info:

Device: Moto G (falcon) Android version: 6.0.1 (CM 13.0) Signal version: 3.25.4 (when I triggered the bug - storage was full)

I just updated to version 3.27.1 (latest version currently at GPlay) and the app still crashes.

Logcat output:

RAW logcat output (gist)

The cause seems to be related to the following line:

01-26 11:17:20.112 22643 22674 W CursorWindow: Window is full: requested allocation 8022473 bytes, free space 2096632 bytes, window size 2097152 bytes

johanw666 commented 7 years ago

You can always manually delete the last record in the messages table if you forgot to make a backup, that should solve the crash. If you are rooted of course, but without root (or a modified version) a decent backup is not possible anyway without a lot of hassle.

2-4601 commented 7 years ago

@primeos Which Signal version? (device info etc. missing from your bug report) Did not test pre-3.28.0 but could be duplicate of #6098

primeos commented 7 years ago

@2-4601 Just added the device info. Shouldn't be a duplicate of #6098 tho (with this bug one can't even launch the app, while the other one only occurs when scrolling to the top (if the description is correct)).

You can always manually delete the last record in the messages table

@johanw666 I don't know how - do you have a link for that? If not that's fine as well (I've made a backup just before testing this).

Update: Added a bug description as well.

johanw666 commented 7 years ago

@primeos : a link for what? How to manually edit a SQLLite table? There are several Android apps for that. Or how to make a backup with adb on a non-rooted device? That requires downgradig to TextSecure version 2.28 or lower and make an adb backup (after that version it is blocked to prevent Google from backing up conversations online).

primeos commented 7 years ago

@johanw666 Seems like I misinterpreted that. I thought there would be a trivial way (compared to editing a SQLLite DB) to delete the last received message, which made me curious.

CaiusCosades commented 7 years ago

tmp_20464-screenshot_2017-01-27-10-31-212056042925 Guys if you are good with computers please fix this asap, I'm gonna lose all my messages, please help It crashes and won't open at all after I received these anonymous multimedia messages Is this the government trying to control our messaging apps? pls help

johanw666 commented 7 years ago

@CaiusCosades : this seems unrelated to the topic, usually this is caused by some malformed message. The solution that usually works here is to put the phone in airplane mode which will allow Signal to open and delete the offending message.

CaiusCosades commented 7 years ago

But it crashes even in airplane mode! And I also tried sending another message to mark all as read, that also didn't help.

Trolldemorted commented 7 years ago

@CaiusCosades i also think this should go into a seperate issue.

Nevertheless, can you run logcat while signal is crashing so we get a hint on what is happening?

primeos commented 7 years ago

@CaiusCosades You're describing a different bug. If you'd be experiencing this bug you wouldn't get any notifications at all (IIRC not even for the message which triggers this bug).

Also for me this looks like you're trolling, so please stop it if that's the case - thanks :smile:

I'm not that familiar with Signal but I guess one would need to have two contacts named Anonymous and Facebook in order to get these messages. And the fact that you just created this account for commenting on that issue makes me suspicious.

CaiusCosades commented 7 years ago

Did I do it right: logreport.txt logreport_airplane.txt - this is with aeroplane mode on

i didn't receive any notifications until i received a message (that means there were no notifications for the anonymous messages, but there was one for that facebook sms) i just want to report a bug so someone can hopefully fix it and i don't want to lose my messages

Trolldemorted commented 7 years ago

@primeos i do not know how, but some sms have sender names attached to them. Even on my 15year old non-smartphone backup handy, sms from my certain providers show up with the company's name in the sms list, and i definitely do not have them in my contact list.

@CaiusCosades yup, looks like a bug. Someone is sending you mms without headers and signal doesn't like that. Please open a seperate issue for that (e.g. "sms with malformed headers crashes signal on startup"), i can fix the NPE easily, but i do not know whether a mms without a header should be considered valid at all.

primeos commented 7 years ago

(triage) Any updates? I assume this isn't considered that relevant (which is ok, even tho I would disagree).

Do you have any suggestions how we could fix this?

I guess there is no valid need for sending such absurdly large messages which is why I would suggest fixing this at the server side (probably simply by passively dropping (or actively rejecting) such messages). I'd assume this would already fix this issue for the receiving client, since the connection to the server should be authenticated via TLS (however this might also be caused by the push notifications and therefore depend on Google servers(?) - but I guess then it still works because they should require an authenticated TLS connection as well). What do you guys think?

Trolldemorted commented 7 years ago

Since my friends use signal to send long messages (source code, logs, etc), i'd oppose an enforced limit, especially since we still cannot send arbitrary attachments with vanilla signal.

primeos commented 7 years ago

@Trolldemorted that's an interesting use case :wink: - But a valid one of course.

However I assume you're usually not sending such long messages that the Android-App would crash, right?

Assuming the message limit of 2096632 bytes is correct and refers to uncompressed UTF-8 text then you would still be able to send ~38% of the text of all seven Harry Potter books in one single Signal message (2096632/(5.1*1084170) - assuming: English average: 5.1 characters/word and the Harry Potter books contain 1,084,170 words).

ghost commented 7 years ago

interesting, in Signal-iOS is an PR to limit size of outgoing messages to 64kb https://github.com/WhisperSystems/Signal-iOS/pull/1846

2-4601 commented 7 years ago

Related #3388.

automated-signal commented 6 years ago

GitHub Issue Cleanup: See #7598 for more information.

signalapp / Signal-Android