search

signalapp / Signal-Android

A private messenger for Android.
https://signal.org
GNU Affero General Public License v3.0
25.16k stars 6.06k forks source link

[Feature] Safely/Securely download a pending MMS message to a user folder. #6629

Closed SamClarke2012 closed 6 years ago

SamClarke2012 commented 7 years ago

I have:

Feature description

I have received an MMS from a number that isn't in my contacts. I'd like to be able to download that data for analysis without signal attempting to display or otherwise interact with it.

Steps to reproduce

strugee commented 7 years ago

What's the usecase here? I don't really see a use for inspecting something without trying to display it, particularly since Signal is written in a memory-safe language. I may be missing something, though.

E3V3A commented 7 years ago

@strugee

... Signal is written in a memory-safe language.

What do you mean with that? There is nothing like a memory safe anything, or we wouldn't have to deal with escaped VM sandboxed malware.

The case is as @SamClarke2012 describe. Because of Stagefright attacks (also vulnerable on AOS 6+) , MMS should never be automatically downloaded and opened. But it should be possible to download the message in binary form, for later maleware inspection.

strugee commented 7 years ago

@E3V3A yes there is. Java is memory-safe. I forgot about Stagefright though, so you're right there.

This still feels too complex though.

SamClarke2012 commented 7 years ago

I wouldn't have predicted that adding a 'download to folder' option on a pending MMS would be very complex, but fair enough. A large number of security professionals, journalists etc use Signal for a secure messaging platform, this option can be an advantage in those cases. For example, a journalist may receive data from an anonymous source. In my particular case, I received an MMS from an unknown number that apparently doesn't officially exist.

And I hate to break it to you, but the JVM isn't bullet proof, never has been and most probably never will be.

E3V3A commented 7 years ago

I wouldn't have predicted that adding a 'download to folder' option on a pending MMS would be very complex

I would also guessed it should be a rather simple task to download the message as a binary blob, without any further processing. Here's one entry point where the MMS already seem to be handled:

MmsDownloadJob.java#L187-L205

What is worrisome in the light of Stagefright related remote MMS attacks (that doesn't even have to be opened), is the processing done by the thumbnail handler. At this point there is no telling what would happen on a vulnerable device, if such a message would be received. OT: It is surprising to see the number of MMS related issues posted here by people on highly vulnerable devices, such as those on AOS < 5.1 (L).

So until we can say that Signal SMS/MMS is not vulnerable to such attacks, I can't help thinking that there should be some sense of obligation from the Signal maintainers, to at least try to provide some kind of information on this issue. Since Signal is gaining a lot in popularity and most people are clueless, to even basic device security, we should not fool ourselves or them, by hiding this problem under the rug. This is already an old exploit, readily available in every Script-kiddie's Kali box. So all it would take is testing and massaging some pointers, which are well documented all around.

So one way to help, would be to be able to safely download the MMS for further analysis. I know many people who has gotten very suspicious messages this way, but without any way to analyze them. Especially since they may only be available for download for a very limited time. There are even people right here in these github issues that have seen this happen. Currently, and AFAIK, there are no other apps or tools available for this. So Signal is the obvious choice for this proposal.

strugee commented 7 years ago

I wouldn't have predicted that adding a 'download to folder' option on a pending MMS would be very complex, but fair enough.

My guess is that it wouldn't be complex in terms of code, but that's not the only type of complexity. There's also UX to consider. It adds interface complexity.

A large number of security professionals, journalists etc use Signal for a secure messaging platform, this option can be an advantage in those cases.

How? What action can a journalist actually reasonably take? They won't have the technical expertise to examine an MMS file at all, much less determine whether it's designed to exploit a security vulnerability and compromise their device.

And I hate to break it to you, but the JVM isn't bullet proof, never has been and most probably never will be.

You're not "breaking" anything to me. But the JVM is quite battle-tested. If your threat model is, the adversary can find and exploit new vulnerabilities in the JVM to come after me specifically, you're all kinds of screwed. Signal really can't help you in this case. At that point you shouldn't be using a phone at all and you should be using Qubes 100% of the time on your computer.

strugee commented 7 years ago

What is worrisome in the light of Stagefright related remote MMS attacks (that doesn't even have to be opened), is the processing done by the thumbnail handler.

To me a good action item here would be, make sure Stagefright isn't invoked with untrusted content. Not "add a new confusing option that 99% of people won't (know how to) use." Remember, the answer is never more options.

E3V3A commented 7 years ago

To me a good action item here would be, make sure Stagefright isn't invoked with untrusted content. Not "add a new confusing option that 99% of people won't (know how to) use.

Exactly my case. Unfortunately, almost all devices with AOS < 6.0.1 are directly vulnerable to remote SF exploit. So accordingly to both our ideologies, Signal should not even support devices on those API's or abandon all SMS and MMS support.

For example, the lady @riyapenn in #6668 might benefit to know, that probably all of her devices can be exploited remotely. (If you don't believe me, send me the phone number to any one of them, and I'll prove it.)

What action can a journalist actually reasonably take? They won't have the technical expertise to examine an MMS file at all, much less determine whether it's designed to exploit a security vulnerability and compromise their device.

That is exactly it! IIRC that was how HackingTeam and Finfisher was exposed. A journalist without tech knowledge managed to pass on the messages to researchers.

Ahmed Mansoor, a prominent human rights activist in the United Arab Emirates, who has been tracked by surveillance software several times, began receiving suspicious text messages. The messages purported to contain information about the torture of U.A.E. citizens. Mr. Mansoor passed the messages to researchers at the Citizen Lab, who confirmed they were an attempt to track him through his iPhone.

So yeah, I don't think a function like what we propose here, is more confusing or less useful, than "disabling screen shots" or "Always relay calls". But it would benefit the entire community in the sense that security researchers could immediately start analyzing new attacks whether it is links to or direct malware MMS.

moxie0 commented 7 years ago

I don't know about downloading an MMS to a "user folder," but an option to disable auto-download of MMS seems fine to me.

SamClarke2012 commented 7 years ago

@moxie0 I think that'd be a great start toward improving the overall security. It's not that I feel a download option should exist just for the sake of it, or for my own personal interest, but I feel that Signal (or any other sufficiently popular messaging app for that matter) has the ability to improve the response time and defense of malware for mobile devices by simply facilitating the isolation of suspicious data for a user to either send to security professional, or analyse themselves if they have the ability.

@E3V3A Thank you for taking the time to detail the background on my brief, and somewhat roughly outlined suggestions, I'm currently sitting exams university and didn't/don't have the time to do it.

SamClarke2012 commented 7 years ago

@strugee is Signal;

a) A security focused messenger that happens to have good UX design b) A UX focused messenger that happens to have good security

I understand that at the end of the day security popularises Signal, and good UX design keeps people using the app, but you should try to understand that the vast majority people (including myself) have stuck with Signal through all sorts of annoying crashes and bugs, some of which have been really quite concerning - this is much more annoying than a minor UX design choice - so perhaps minor UX choices in the case of Signal aren't as important to users as you think.

By the same token, bolstering the 'security conscious' ethos of Signal by allowing users to report suspicious data to malware researchers may further popularise Signal by way of further promotion within the security community - and perhaps gov't agencies if they can do their own analysis. This leads me back to my initial (rhetorical) question.

ghost commented 7 years ago

JFYI in Silence is already an option to disable MMS auto-download (see https://github.com/SilenceIM/Silence/commit/21de972891a45b9a13925015dc50798e069ba2a2)

E3V3A commented 7 years ago

@SamClarke2012 I couldn't have said it better. I have the same exact experience with Signal and have also been the strongest promoter for using it among my friends etc. It was designed by @moxie0 for security or at least academic interest thereof.

@p4nci Unfortunately disabling automatic downloads (from this app) doesn't prevent automatic downloads from other apps. AFAICR you need to have root to manipulate that functionality on system level of the app? (But I haven't checked lately as I am always root.) So its futile. In addition, this issue is not about that, but about being able to save the resulting URL response/request data-streams (or whatever you want to call it, you get my point) without any other intervention by the device OS or other messaging apps.

ghost commented 7 years ago

@E3V3A

  1. moxie0 clearly said "but an option to disable auto-download of MMS seems fine to me."
  2. Silence is (or better was) a Signal (TextSecure) fork, so for those who want to implement 1. may look into it
SamClarke2012 commented 7 years ago

Let's also not disregard the fact that StageFright has been extended to MP3/MP4 files too [1]. Making decisions based on the current security climate isn't a sufficient defense for what we (mostly) all know is an ever developing attack vector.

  1. https://blog.zimperium.com/zimperium-zlabs-is-raising-the-volume-new-vulnerability-processing-mp3mp4-media/ - sourced via https://www.acsc.gov.au/news.html
E3V3A commented 7 years ago

It's extremely disappointing to see that ~8000 stargazers and 2000+ forks of Signal, does not seem to be interested in basic device Security at all. (Why even bother using this app?) The bottom line:

To @moxie0 (or whoever is maintaining the development of this app): If we would provide a PR for implementing the fore-mentioned feature, would you add it to Signal?

This would basically involve 3 steps:

Note: * The proposed disable MMS download checkbox is useless, as most people have at least 3 other MMS messaging handlers on their phones (OEM, WhatsApp, Viber and possibly Facebook), that would likely ignore your setting. In addition, such a "setting" is already present in the native phone messaging settings. The explanation of the checkbox would be that if enabled, the message will not be visible, while if it is disabled, it will be displayed and handled as usual, according to phone settings.

moxie0 commented 7 years ago

The proposed disable MMS download checkbox is useless, as most people have at least 3 other MMS messaging handlers on their phones (OEM, WhatsApp, Viber and possibly Facebook)

WhatsApp and Viber do not handle MMS, and Android only allows a single app to be a registered SMS/MMS handler at a time.

If what you're interested in doing is facilitating is the transfer of MMS payloads to third parties, the url is all that they should need (which is already in the log). Downloading malware to a device and then somehow transmitting it to someone else without that malware ever being "processed" as a media file is not likely to end well.

automated-signal commented 6 years ago

GitHub Issue Cleanup: See #7598 for more information.