Navigation to restricted origins via "Open in new tab"
State Resolved (Closed)
Disclosed publicly 2018-10-09T23:16:23.617Z
Reported To
Weakness none
Bounty $50

submitted a report to Brave Software .


It's possible to open links pointing to file:/// origin from web pages using "Open link in a new tab" in context menu. shows unsafe ssh:// protocol handling, which leads to information leak using ssh(OS username and etc.). The vulnerability is highly available, so it's possible to leverage it.

As of, we could get username, it's easy to predict path of the downloaded file:


When user initiates ssh session through browser, it's equal to running ssh [email protected]. So the host which receives connection request knows user's OS username.


DOWNLOADED_FILE_NAME is download attribute of the link. That means, it's under the attacker's control.

Products affected:

Brave 0.22.810
rev 8f30eeb
Muon 7.0.6
OS Release 17.6.0
Update Channel Release
OS Architecture x64
OS Platform macOS
Node.js 7.9.0
Brave Sync v1.4.2
libchromiumcontent 67.0.3396.71
OS: macOS 10.13.5 17F77 x86_64

Steps To Reproduce:

Live PoC:

I could provide a PoC with "ssh step", if it could increase a bounty. Currently, OS username is hardcoded in exploit.html. Insert your OS username to run the exploit. (e.g. using devtools or locally)

  1. Webpage requests navigation to ssh:// - user agrees.
  2. Navigation happens, attacker's host received ssh connection request. Attacker knows user's OS username.
  3. Webpage asks to download the file. Let's name it file-load.html. Downloading happens.
  4. User opens a link(using "Open in a new tab") which points to file:///Users/${USERNAME_FROM_SSH}/Download/file-load.html
  5. Navigation happens, downloaded HTML file executes on local file system.

Screencast attached.


Navigation from web pages to file:/// and executing downloaded (from the web) files on local filesystem is definitely a vulnerability, which additionally opens a wider attack surface for an attacker.

Bypassing SOP on file:/// origin could lead to a full-chain exploit 😈.


metnew Activities::Comment
Also, `chrome-extension://` is accessible too, that means, it's possible to open internal `about:*` urls.

metnew Activities::Comment
fix typo: `file:///Users/${USERNAME_FROM_SSH}/Download/file-load.html` -> `file:///Users/${USERNAME_FROM_SSH}/Downloads/file-load.html`

rubikcube Activities::Comment
Hi @metnew Thanks for your submission. We are currently reviewing your report and will get back to you once we have additional information to share. Kind regards, @rubikcube

glassofbeer Activities::BugTriaged
@metnew We were able to technically validate your issue and will now escalate it to the internal team for evaluation on whether this is something they want to take a deeper look into. We will get back to you as soon as we have any news. Best Regards,

pranjal_jumde Activities::Comment
Tracked here:

metnew Activities::Comment
> Also, I'd like to report more vulnerabilities, but I'm out of trial reports and I'm worrying that fix for this issue could resolve other unreported vulnerabilities. Is there any way I could submit my research on Hackerone? @glassofbeer @pranjal_jumde

metnew Activities::Comment
Hi @pranjal_jumde @glassofbeer @rubikcube I've just found #375329 - "Local files reading using `link[rel=import]`" which makes this bug critical.

diracdeltas Activities::ReportSeverityUpdated

metnew Activities::Comment
Is it possible to keep this issue opened for a while? Seems like I've got a better PoC for this case which could increase the severity again to "High"

Thank you for the report.

metnew Activities::Comment
> Note: this bug also allows to open internal pages - `chrome://` and `chrome-devtools://` :(

metnew Activities::Comment
Probably, closed, since was merged

diracdeltas Activities::Comment
it appears doesn't fix this issue. 'open in new tab' still allows file:// to be opened

metnew Activities::Comment
> I've accidentally commented on the wrong report, sorry :)

metnew Activities::Comment
Fixed in 0.23.80 -

diracdeltas Activities::BugResolved

metnew Activities::Comment
@diracdeltas This bug easily allowed to increase the severity of #390362 and #375329 to Critical: > In lokihardt used local reflected XSS to execute script in `` context -> RCE ### Versions Brave patched this bug after fixing #375329 and #390362 -> severity of both bugs could be increased. ### Reflected XSS on local filesystem I guess, as of Brave supports macOS (and older versions) `System/Library/PrivateFrameworks/Tourist.framework/Versions/A/Resources/en.lproj/offline.html` would be considered as valid. Additionally, we could try to find any reflected XSS in Win/Linux/other supported platforms. Also, it's possible to find reflected XSS in Brave's `app.asar`. ### Attack scenario 1. User opens link using "Open in new tab" 2. The link points to any default system HTML files with reflected XSS (e.g. `/System/Library/PrivateFrameworks/Tourist.framework/Versions/A/Resources/en.lproj/offline.html?redirect=javascript%253a<PAYLOAD>";` 3. `<PAYLOAD>` steals local files + sends to attacker's server.

metnew Activities::Comment
And also [#395737]( could be "level-up"ed to Critical.

diracdeltas Activities::Comment
@metnew the chrome bug you linked to ( was fixed in 2017, so i don't think it would have been present in Brave at the time that your report was opened. It's true that it would have been present from Brave's release in 2016 to sometime in early 2017, but we don't consider already-fixed bugs in-scope for a report.

metnew Activities::Comment
Yeah, this bug from GPZ just inspired me to re-think submitted bugs, it was reported in late 2016. Such an attack is possible. However, as of reflected XSS on `file://` is required, attacker should have some info about the victim's system (e.g. installed apps). @diracdeltas

metnew Activities::AgreedOnGoingPublic

metnew Activities::Comment
@diracdeltas I don't find a reflected XSS in default macOS installation :( However, by default macOS includes `/System/Library/CoreServices/Photo Library Migration` file. This file on local filesystem requires a Google maps script from the web. However, the most interesting thing is that it requires this script with plain `http:// `. That's unsafe. MITM => running own scripts on `file:///` origin. Yeah, so that means an attacker with a MITM access can "level up" any bug that requires running scripts on `file:///` origin. > Tested on the latest High Sierra.

diracdeltas Activities::Comment
My understanding is that due to a MacOS bug (loading files over HTTP), a MITM could load an arbitrary file onto the users' filesystem. Then they could trick a user into executing this file if the user visits their website by telling them to click 'open in new tab'. I don't think the MacOS bug significantly increases the severity of this issue, since it is mac-only and still requires the attacker to do some tricks (as well as have local network access).

metnew Activities::Comment
### Distinguish vulnerabilities in different OSs? @diracdeltas I think that's a bad practice to distinguish vulnerabilities in different OSs and assign severity based on a number of OS where exploitation is possible. This practice is ok when we're dealing with Web vulnerabilities (like XSS in modern vs outdated browsers) but in OS... Honestly, I think this approach is wrong (in the context of OS). I've never seen this in programs with native apps.

metnew Activities::Comment
@toml, Could we disclose this? Also, the title is misleading. `Navigation to restricted origins via "Open in new tab"` sounds better.

metnew Activities::Comment
So, I guess we could disclose this report after changing the title, am I right? @diracdeltas @toml

toml Activities::ReportTitleUpdated

toml Activities::AgreedOnGoingPublic

toml Activities::ReportBecamePublic