1422467 - about:cache XSS

Status: RESOLVED FIXED

(Core :: Networking, defect, P3)

Description

[Abdulrahman Alqabandi]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

1. Visit: about:cache-entry?storage=memory&context=&eid=<svg/onload=alert(location)>&uri=http://aa.com
2. Visit: about:cache?storage=memory&context=


Actual results:

XSS

Comment 1

[:Gijs (he/him)]

There's no straightforward way for a webpage to link to these, so this is effectively self-xss, for which there are more convenient methods, right? :-\

I think this is sec-low at best and should be opened up.

Comment 2

[Abdulrahman Alqabandi]

(In reply to :Gijs from comment #1)
> There's no straightforward way for a webpage to link to these, so this is
> effectively self-xss, for which there are more convenient methods, right? :-\
> 
> I think this is sec-low at best and should be opened up.

From a previous bug in the same about page it was rated sec-moderate, for what that's worth. Bug 1074485
Though this one does take 2 user actions rather than just one. But again the previous bug was from 2014 which were different times :)

Comment 3

[:Gijs (he/him)]

Honza, can you take a look, as you fixed bug 1074485? :-)

Comment 4

[Honza Bambas (:mayhemer)]

I *think* this is sec low, but feel free to fix me please.

Comment 5

[Abdulrahman Alqabandi]

According to https://wiki.mozilla.org/Security_Severity_Ratings :
"sec-low
Minor security vulnerabilities such as leaks or spoofs of non-sensitive information. Missing best practice security controls"

Now although about: pages are not linkable from normal web pages I think its not far fetched to think of this as a stepping stone for a far more severe (sec-high+) exploit.

For example, I currently have two bugs within web extensions that allow opening of privileged about: pages. Bug 1425224 and bug 1425267. I could theoretically use one of those bugs with this one to create a more severe exploit. Bug 1310183 for example was marked sec-high because you could read sensitive user information due to a bug that resulted in the direct reading of about:cache. Quote from Daniel Veditz: "..the URLs in the cache contain a lot of potentially private information, both the sites you're visiting and possibly passwords or session IDs etc in parameters."

Now if you look at the brief description of "sec-moderate" you will read the following: 

"Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a _violation of privacy_ but by itself does not expose the user or organization to immediate risk. The vulnerability combined with another moderate vulnerability could result in an attack of high or critical severity (aka stepping stone)." 

So since this bug can be used with another moderate bug that results in sec-high violation of privacy it should then be marked as sec-moderate.

Comment 6

[Honza Bambas (:mayhemer)]

Attachment: v1

I checked (hopefully) all places we build the output at.  There were few other places to escape, not just the eid printout.

And have to say - a good catch!  Thanks.

Comment 7

[Honza Bambas (:mayhemer)]

(In reply to Abdulrahman Alqabandi from comment #5)
> So since this bug can be used with another moderate bug that results in
> sec-high violation of privacy it should then be marked as sec-moderate.

Based on "Client bugs that might have high or critical results but require the user perform unusual or complex actions to trigger" this is sec-moderate.

Changing.  Thanks.

Comment 8

[Honza Bambas (:mayhemer)]

Comment on attachment 8938081 [details] [diff] [review]
v1

[Security approval request comment]
How easily could an exploit be constructed based on the patch?

  It's relatively obvious what one should do (put an html code to one of the URL parameters)


Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

  No comments, no tests (about:cache doesn't have tests)


Which older supported branches are affected by this flaw?

  All of them, this is in the code since 32.


If not all supported branches, which bug introduced the flaw?

  The offending line first appeared in bug 916052.


Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

  This should apply cleanly, since this code is has not changed for a long time.  Risk is zero.


How likely is this patch to cause regressions; how much testing does it need?

  Zero chance.  This is a change on an internal diagnostic page only.  If we break something here it's not a big deal.

Comment 9

[:Gijs (he/him)]

You don't need sec-approval for sec-moderate bugs, only for sec-high/crit ( https://wiki.mozilla.org/Security/Bug_Approval_Process ).

Comment 10

[Honza Bambas (:mayhemer)]

(In reply to :Gijs from comment #9)
> You don't need sec-approval for sec-moderate bugs, only for sec-high/crit (
> https://wiki.mozilla.org/Security/Bug_Approval_Process ).

Had to look. thanks.

Comment 11

[Honza Bambas (:mayhemer)]

Comment on attachment 8938081 [details] [diff] [review]
v1

Approval Request Comment
[Feature/Bug causing the regression]: bug 916052
[User impact if declined]: possible but complicated XSS on a chrome (about) page
[Is this code covered by automated tests?]: no, no tests for about:cache ever
[Has the fix been verified in Nightly?]: locally only
[Needs manual test from QE? If yes, steps to reproduce]: comment 0 reproduces with 100% reliability and it's easy
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: a simple change to a diagnostic non-critical about page
[String changes made/needed]: none

Comment 12

[Julien Cristau [:jcristau]]

Feels like this can ride the trains to 59.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b6df8ef5dec1

Comment 14

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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