948604 - [Email][RTSP] RTSP link isn't recognized as RTSP hyperlink in email

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[sarsenyev]

Attachment: screenshots.zip

Description:
When a rtsp link is received over email, the link is no recognized as RTSP link and opened as http link

Prerequisites:
Email is set up on the device

Repro Steps:
1) Updated Buri to BuildID: 20131210004003
2) Send the "rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov" link over email to the device
3) Open the email app on the device
4) Observe the link, the "rtsp" link is not recognized as RTSP hyperlink

Actual:
The "rtsp" link is not recognized as RTSP hyperlink but opened as HTTP link

Expected:
The hyperlink can be opened as RTSP file

Environmental Variables:
Device: Buri 1.3 Aurora Moz RIL
BuildID: 20131210004003
Gaia: 3452fbdb5e1bed0cd27cc6173136537a03e8072f
Gecko: e0c328d99742
Version: 28.0a2
Firmware Version: v1.2_20131115

Notes:
Repro frequency: 100%
It reproduces on Gmail, Yahoo, Hotmail...etc
See attached: screenshot

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

huh, interesting.  So, we explicitly only support http/https URL-style links for security-ish reasons[1].  But given the text:
  rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
We linkify the portion:
  184.72.239.149/vod/mp4:BigBuckBunny_115k.mov

We do this because we would linkify that if we just saw it on our own and we do nothing to stop ourselves from having our transformative regexp skip over this.  This will be resolved by switching to a non-regexp based parser on bug 858370.


1: The security reason for this is less strong on Firefox OS, and it's possible we should just be white-listing rtsp.  For Thunderbird / desktop computers it can be dangerous to allow triggering non-http based URLs because it can trigger desktop applications that were not written with security in mind and either allowed buffer overflows or direct triggering of unsafe operations.

In the case of Firefox OS, protocol handlers in general are less dangerous because:
- buffer overflow exploits are less of a thing
- poorly implemented parsing is less of a problem because applications run in limited-capability web contexts where dynamic code execution by eval/friends is basically impossible.

Needinfo-ing Adam to ask:
1) Is RTSP something we should just white-list in the e-mail app?  I'm not sure what actually would handle it, but maybe something does?
2) Should we consider loosening up our protocol filter in general?  We still need to ask freddyb, who I'll needinfo next.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

:freddyb, please see comment 1 and comment on what you think the necessity of/most appropriate protocol-filtering level is for linkification.

Comment 3

[Jason Smith [:jsmith]]

Just a FYI - RTSP has moved to 1.4, so this would bug would only be applicable to 1.4+.

Comment 4

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #3)
> Just a FYI - RTSP has moved to 1.4, so this would bug would only be
> applicable to 1.4+.

Actually that's a misinterpretation of comment 2 on bug 948564 - basics of RTSP is still listed on the roadmap for 1.3. However, this doesn't appear to be a requirement for the basic RTSP support.

Comment 5

[Frederik Braun [:freddy]]

(In reply to Andrew Sutherland (:asuth) from comment #1)
> 2) Should we consider loosening up our protocol filter in general?  We still
> need to ask freddyb, who I'll needinfo next.

If there's RTSP support coming in, we should probably support it from the email side of things. Especially if it's supported from within Gaia.
I'm OK with loosening the whitelist from time to time but we surely want to stick with a whitelist.


I wonder if we have a central doc that summarizes all the previous security considerations of linkifying text in emails? Could there be something from Thunderbird as well?

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Frederik Braun [:freddyb] from comment #5)
> I wonder if we have a central doc that summarizes all the previous security
> considerations of linkifying text in emails? Could there be something from
> Thunderbird as well?

So, for Thunderbird, there are two things could come into play, I believe, the linkifier and the content policy used for message display.

For the linkifier, you have lucked into asking about some of the only code in Gecko/Thunderbird that not only has useful comments but also a design doc.  From https://bugzilla.mozilla.org/show_bug.cgi?id=858370#c1 and above:
http://www.bucksch.org/1/projects/mozilla/16507/
http://www.bucksch.org/1/projects/mozilla/31906/
http://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/mozTXTToHTMLConv.h
http://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp

ShouldLinkify makes the protocol-based decision and can be found here:
http://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp#389

ShouldLinkify seems to linkify anything that Thunderbird knows how to handle or that has an external app associated that can handle it.  Note that Firefox and Thunderbird in my experience have not been great with integrating with with the platform automatically, so it's possible Thunderbird frequently has no idea of what the system is actually capable of.

The content policy in Thunderbird likes to block everything but http/https/file other than its own internal protocols:
  http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgContentPolicy.cpp#411
But that only happens at ShouldLoad time, so it seems like maybe that would not affect our display, just our willingness to let the user actually effectively click on the links?  I'm a bit confused without doing more tracing.


In any event, BenB who I believe wrote most of the linkifying code is still around and is very helpful, so needinfo'ing him in case he has any info/suggestions on this front.  Thanks in advance for any insight you can provide, ben!

Comment 7

[Ben Bucksch (:BenB)]

> For the linkifier, you have lucked into asking about some of the only code in
> Gecko/Thunderbird that not only has useful comments but also a design doc.

Thank you for this huge compliment :)

> Thanks in advance for any insight you can provide, ben!

With pleasure.

How it works:
I just create an nsIURI for the string URL, and if that works, I have a valid - and usually working - URL. IOService is nice enough to find the right URI implementation for my scheme, and the implementation should also check the form of the URL, so I'm getting automatic protocol-specific validation. (In theory - e.g. the mailto implementation is a dummy.) This is in function CheckURLAndCreateHTML(), line 421-444
http://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/mozTXTToHTMLConv.cpp#421
The main smarts are in the innocently looking line 440
rv = mIOService->NewURI(...)

This code evolved over the years, so now it's making additional checks for external helper apps. That's what ShouldLinkify() does, but the main check is the NewURI().

----

As for which URL schemes we support:
* Everything that Mozilla supports
* External helper apps configured in Mozilla
* External helper apps configured in Windows using the Registry

So, if you install a tel app that registers "tel" URLs in Windows, Mozilla should automatically recognize that. If you click on such a URL in Firefox, it should work and open the app. You don't need to configure Firefox, because it looks in the Windows registry.
Same should happen in Thunderbird. Try that by opening such a URL in a browser window in Thunderbird.
Now, if you can open the URL in the browser, then the above code should also recognize such URLs in plaintext.

Comment 8

[Ben Bucksch (:BenB)]

> For Thunderbird / desktop computers it can be dangerous to allow triggering non-http based URLs
> because it can trigger desktop applications that were not written with security in mind and
> either allowed buffer overflows or direct triggering of unsafe operations.

Not really. The whole purpose of this Windows URL scheme registration is to be started from a link on a webpage. Then there were exploits in Windows help, and they tightened up (luckily). IIRC, an app registering itself in Windows can mark itself as "safe" or not. If safe, it wants to be accessible by clicking on links in a webpage.

In Thunderbird's recognizer, the intention is to recognize all URLs that a webbrowser could open from <a href="foo:bar"> links. (We don't promise that, it's just a heuristic and it can't recognize everything, but that's the intention.)

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Ben Bucksch (:BenB) from comment #8)
> Not really. The whole purpose of this Windows URL scheme registration is to
> be started from a link on a webpage. Then there were exploits in Windows
> help, and they tightened up (luckily). IIRC, an app registering itself in
> Windows can mark itself as "safe" or not. If safe, it wants to be accessible
> by clicking on links in a webpage.

I definitely misunderstood what Thunderbird was actually doing when I wrote that and was trying to reverse-analyze the rationale.  I just did a quick search to try and validate my memory, and it seems like protocol exploits are still a thing although it's gotten better in terms of the Operating Systems having plugged the holes and most of the exploitable software frequently being auto-updating.  I was surprised to find that iOS has had such exploits!  But I guess it comes with the territory of compiled code where buffer exploits are possible.

* Origin game platform protocol vulnerability
http://arstechnica.com/security/2013/03/bug-on-eas-origin-game-platform-allows-attackers-to-hijack-player-pcs/

* Steam protocol exploit through triggered games, not steam itself:
http://arstechnica.com/security/2012/10/steam-vulnerability-can-lead-to-remote-insertion-of-malicious-code/

* skype ios protocol triggering calls without prompting:
http://software-security.sans.org/blog/2010/11/08/insecure-handling-url-schemes-apples-ios/

* skype in general seems to have a history of protocol handler exploits on windows:
http://www.cvedetails.com/vulnerability-list/vendor_id-2302/product_id-4023/Skype-Technologies-Skype.html

* and some skype data-loss vulns on IOS too?
http://seclists.org/bugtraq/2010/Mar/116

* Win XP/2003 shell32.dll url-handling exploit (affecting outlook express protos/telnet ?):
http://technet.microsoft.com/en-us/security/bulletin/ms07-061
http://www.iss.net/security_center/reference/vuln/Windows_URI_Command_Exec.htm

* Mac telnet, disk, disks, help:
http://daringfireball.net/2004/05/telnet_protocol
http://daringfireball.net/2004/05/unsafe_uri_handlers

* Windows shell protocol triggered by Firefox (although the exploit was meta refresh):
http://arstechnica.com/uncategorized/2004/07/3972-2/

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

Er, and what I meant to also say was that just because an app marks a protocol safe doesn't mean it is safe.  I think most uses of custom protocols are for the purposes of directly launching something native from a web browser with arguments specified.  If they didn't mark themselves safe, their goal would not be achieved so they are compelled to mark themselves safe, regardless of actual safety/competence.

Comment 11

[Ben Bucksch (:BenB)]

Well, if they remove the safety lock, that's their problem. Power socket + 2 needles = bzzzz; not the fault of the socket.
Unlike HTML+JS, the recognizer is not launching the URLs automatically, just allowing the click. And unlike HTML, the URL here is in plain text and plain sight before the user acts on it.

It boils down to the fact that Firefox would have the same problem, and much more severe, due to automatic execution, e.g. function onLoad() { window.location = "tel:myexploitcodehere" }.

Comment 12

[Frederik Braun [:freddy]]

Wow. that was a long read!
Given all this information, I think it's OK to linkify RTSP as long as we know a handler for it.
Ben: Please speak up if I'm mistaken ;)

Comment 13

[Ben Bucksch (:BenB)]

> I think it's OK to linkify RTSP as long as we know a handler for it.

Agreed

Comment 14

[Adam Rogers (:arog)]

Agreed on white-listing RTSP. 

I'd like to see a more comprehensive risk analysis before generally opening up the filters

Comment 15

[Verson Xiong (Leave from Mozilla)]

Attachment: Aries_v2.5.png

This issue also reproduces on latest build of Aries kk v2.5.
Result: The "rtsp" link is not recognized as RTSP hyperlink but opened as HTTP link.
See attchment:Aries_v2.5.png

Device: Aries KK 2.5(Affected)
Build ID               20150810003528
Gaia Revision          09dea2d5ff21cdb56da35fe4aa5bf4c90cf1da7f
Gaia Date              2015-08-09 17:11:47
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/0e269a1f1beb
Gecko Version          42.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150810.000017
Firmware Date          Mon Aug 10 00:00:24 UTC 2015
Bootloader             s1

Comment 16

[BMO Automation]

Firefox OS is not being worked on