1196267 - URL and error message spoofing in about:neterror

Status: REOPENED

(Core :: DOM: Core & HTML, defect, P5)

Description

[Juho Nurminen [:jupenur]]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36

Steps to reproduce:

Create a link pointing to the following URL. Click it.

about:neterror?@bankofamerica.com&e=nssFailure2&u=&d=%F0%9F%90%9E%20The%20website%20you%20tried%20to%20access,%20https://www.bankofamerica.com/,%20appears[e-mail]%20for%20support.


Actual results:

A Firefox error page is displayed, with a message reflected from the link URL. On Firefox for Android the URL in the URL bar is highlighted as if the origin were actually bankofamerica.com.


Expected results:

1. Linking to about:neterror should not be possible.
2. On Android, the neterror URL should not be highlighted so that it can be mistaken for a different origin.
3. Messages should not be reflected to the page from the neterror URL; instead they should be mostly static, with dynamic (potentially attacker-controlled) parts clearly marked as such, for example by placing a border around them and limiting their length and row span.

For the URL highlighting part this is somewhat related to bug 1195976.

Comment 1

[Juho Nurminen [:jupenur]]

Attachment: Screenshot of the behavior on Android

Comment 2

[Juho Nurminen [:jupenur]]

Whoops, sorry, the example URL is missing a slash after bankofamerica.com. That's required to trigger the highlighting bug. Here's the working URL:

about:neterror?@bankofamerica.com/&e=nssFailure2&u=&d=%F0%9F%90%9E%20The%20website%20you%20tried%20to%20access,%20https://www.bankofamerica.com/,%20appears[e-mail]%20for%20support.

Comment 3

[Daniel Veditz [:dveditz]]

Now that we added a mechanism to keep about:reader links from being linkable we should do the same for about:neterror -- and then check more of our unprivileged about links.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Firefox seems to override the default about:neterror (don't know why), so, not sure if this is 
docshell or firefox issue.

Comment 5

[Juho Nurminen [:jupenur]]

The Android URL highlighting issue might be bug 1199601. Not sure though, considering it's Android-only.

Comment 6

[Daniel Veditz [:dveditz]]

Minor spoofing bugs do not meet the bounty qualifications.

Comment 8

[Valentin Gosu [:valentin] (he/him)]

I've checked that the link cannot be loaded when clicked, nor can we navigate to it via location.href.

https://jsfiddle.net/mozvalentin/3zaocd5v/6/

Comment 9

[Daniel Veditz [:dveditz]]

The problem still exists. The mitigations on accessing the link are why this bug was rated sec-low instead of sec-moderate (or sec-high if scripting were possible). Those mitigations make it hard to get to the error page, but if other minor security bugs were found that let an attacker get around the mitigations, the param-passing design of about:neterror is dangerous. For example, one of our error-throwing features might forget to escape things or incorporate too much of the user's input into the error message.

The URL in comment 2 doesn't show the problem any more since we've split about:neterror and about:certerror. Here's an equivalent with a different error code:
about:neterror?e=dnsNotFound&u=https%3A%2F%2Fevil.com&d=%F0%9F%90%9E%20The%20website%20you%20tried%20to%20access,%20https:%2F%2Fwww.bankofamerica.com%2F,%20appears[e-mail]%20for%20support.

The primary offender is nsDocShell::DisplayLoadError(). Even if it's safely creating formatted strings, the fact that it's formatting them outside of the neterror page itself means neterror has to accept and display arbitrary string arguments. If it passed the errorDescriptionID as an about:neterror param and let about:neterror do the intl lookup and formatting instead then this particular injection wouldn't be possible. There may be others in this code, in other arguments—this is just the low-hanging fruit example.