Closed Bug 1718464 Opened 5 years ago Closed 5 years ago

Path Traversal To The System Files

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mawanoffice, Unassigned)

Details

(Keywords: reporter-external, Whiteboard: [reporter-external] [client-bounty-form] [verif?])

A few days ago, I saw a security report in the below URL-
mozilla.org/en-US/security/advisories/mfsa2016-82

It was amazing and after that, I started URL based security research. And today, I found something interesting on Firefox web browser. First look at the below URL-
file://google.com/form/file/e2dsf4G5454S45ES4sdj2Ffk1zYjk5sd7weW78s6C6sdf7878w5w45e7x5d5fgT72s245dsd57fs54Ss5asOsY4Zisud4iIlasi7sdURusldfs9sdgGsllsf5sdYjsts8sjh23sjhPTRksdk8a4G5454S45ES4sdj2Ffk1zYjk5sd7weW78s6C6sdf7878w5w45e7x5d5fgT72s245dsd57fs54Ss5asOsY4Zisud4iIlasi7sdURusldfs9sdgGsllsf5sdYjsts8sjh23sjhPTRksdk8a4G/../../../etc/passwd

When someone will look at the link, he will think- it is Google's URL. But, no! Actually, when someone will click on the above link, the '/etc/passwd' file will be showed on the web browser. What actually happens here is- path traversal. I tested the issue on Linux machine and by this types of URL, an attacker can show any sensitive system file on web browser i.e. '/etc/shadow' if the victim is root user.

Some questions:
(Q) Is it a vulnerability of Firefox or, a vulnerability of 'file://' URI scheme?
(Ans) It is a vulnerability of Firefox web browser. When I tried the attack on an another web browser, it didn't showed '/etc/passwd' file. If it was a vulnerability of the file URI scheme, then it would work on every browser.

(Q) On which operating system, you tested the vulnerability?
(Ans) I tested on Linux machine.

Impact:
When a victim will see the spoofed URL, he will think it as a Google file's URL. Now, writes some Javascript code in his website so that, when a victim clicks on the link, his '/etc/shadow' file will be accessed by file upload functionality. Now, when a victim will see the URL, he will think- he is clicking a Google URL. But, at the moment he clicks on the link, his '/etc/shadow' file will be accessed by the attacker's website and it will be uploaded to the attacker's database. There will be no CORS issue.
2. An office admin is sharing his screen on an online meeting. The attacker works at the company and sends the above URL to the office admin, as his job assignment. So, when admin/boss looks the URL, he thinks- it is Google's URL and clicks on the URL. As soon as he clicks on the link, his '/etc/shadow' file will be shown to the attacker and he will take a screenshot and compromise the admin's computer.
3. An attacker develops website as a freelancer and he sends his html file to his client. Attacker's client was sharing his (client) screen to show how the website looks like. But, the attacker added an iframe in the html file with above URL. So, when the client opens the html file in Firefox, his '/etc/shadow' file will be shown in iframe and as he was sharing his screen, the attacker will take screenshot of his '/etc/shadow' file.

Flags: sec-bounty?

In the place of Google.com, any domain name can be used to do the attack.

Several problems with turning this into an attack:

  1. victims will never be able to click on a file:// link in a web page -- it simply won't work. It will only work from another local file document.
  2. the eventual site will clearly show it is the shadow file and not the spoofy fake thing. Web links redirect all the time -- people need to check the final URL and not trust what it looks like when they click.
  3. "file upload" is not involved IN ANY WAY. It's displaying the contents of a local file. In the same way an attack site could have a link to gmail.com but that doesn't mean they can read your mail.
  4. your scenario involving malicious screen-sharing could compromise data from a lot of victim sites (their web mail? their bank account data?). It could work, but it's going to tank the attacker's freelancer business.

As noted above it still wouldn't work from a "web" site because those can't link to file:// urls. You did mention "send his html file" and yeah, if someone sends you malicious html and you open that as a file: url it could frame (but NOT read) other file: urls. Why doesn't the attacker just send a malware .exe and tell the victim it will install the website? This is an abuse of trust more than a flaw in Firefox.

All the browsers interpret the "path traversal" the same, and in the context of file:// urls that's not a problem. Firefox, however, is ignoring the host part (because hosts don't make sense for local files) while Chrome is treating it as an error ("unknown file"). Safari interprets the URL like Firefox but has different handling (opens the file externally, not in the browser).

I wonder if we could treat host parts as an error now?

Group: firefox-core-security → core-security
Type: task → defect
Component: Security → DOM: Navigation
Product: Firefox → Core
Group: core-security → dom-core-security

So, it won't be considered as a vulnerability?

And, although file://.... won't be any clickable link, anyone copy the URL and go to the link. If Firefox showed an error then, it would not happen.

This is actually a 'passive backdoor'.
But, how?
The answer is- the URI I showed, can be added to a victim’s website as an iframe by any developer attacker. But, it will be spoofed like the URI of the below article:
mozilla.org/en-US/security/advisories/mfsa2016-82)

So the victim will think- it’s a URI of a Google’s file. So, he won't mark it as malicious. Now, as soon as the victim hosts the website on internet, the attacker will open the website in Firefox and he will see the /etc/shadow file in website's iframe. Now, he can totally compromise the victim's website. Though, It’s not any direct backdoor but, it is a 'passive backdoor'.

And if, an attacker works as a web developer in a site and that website added another trusted website in Access-Control-Allow-Origin header then, there can be added my passive backdoor.

PoC:
a.com and b.com allow to access each other's file. Now, the attacker adds an html code in a.com like below:

<iframe src="file://b.com/adminPermited/filePath/e2dsf4G5454S45ES4sdj2Ffk1zYjk5sd7weW78s6C6sdf7878w5w45e7x5d5fgT72s245dsd57fs54Ss5asOsY4Zisud4iIlasi7sdURusldfs9sdgGsllsf5sdYjsts8sjh23sjhPTRksdk8a4G5454S45ES4sdj2Ffk1zYjk5sd7weW78s6C6sdf7878w5w45e7x5d5fgT72s245dsd57fs54Ss5asOsY4Zisud4iIlasi7sdURusldfs9sdgGsllsf5sdYjsts8sjh23sjhPTRksdk8a4G/../../../etc/shadow">...</iframe>

So, the administrator will think- this URI scheme will show b.com's permitted file in iframe. But, actually it will show web server's own /etc/shadow file.

An attacker can also inject this type of URI scheme link in a website. As the website owner won't know about my 'reported bug' he won't filter these types of URI. So, now the attacker can access web server's /etc/shadow file and compromise.

In addition to the above comment, the attacker can inject in the comment section easily.

Update Alert!

This bug can be used with 'https' too.
Look at the below URL-
https://youtube.com/channel/entertainment/blockbuster/episode/new/../../../../../../@file://google.com/form/file/e2dsf4/../../../../../../etc/passwd

If someone clicks on the above URL, browser will go to-
https://www.youtube.com/user/etc/passwd

So, an attacker can send the below URL to victims and redirect them to their own cahannel-
https://youtube.com/real/channel/url/../../../../@file://google.com/form/../../../../attackers/channel

Victim will think- it is intended channel by looking at the beginner part of the URL. This will happen because browser is path traversing by '../../' signs.

(In reply to Md. Abdullah Al Mamun from comment #5)

And, although file://.... won't be any clickable link, anyone copy the URL and go to the link. If Firefox showed an error then, it would not happen.

And if they do, they will see their own file. Not a problem.

(In reply to Md. Abdullah Al Mamun from comment #7)

PoC:
a.com and b.com allow to access each other's file. Now, the attacker adds an html code in a.com like below:

<iframe src="file://b.com/adminPermited/filePath/e2dsf4G5454S45ES4sdj2Ffk1zYjk5sd7weW78s6C6sdf7878w5w45e7x5d5fgT72s245dsd57fs54Ss5asOsY4Zisud4iIlasi7sdURusldfs9sdgGsllsf5sdYjsts8sjh23sjhPTRksdk8a4G5454S45ES4sdj2Ffk1zYjk5sd7weW78s6C6sdf7878w5w45e7x5d5fgT72s245dsd57fs54Ss5asOsY4Zisud4iIlasi7sdURusldfs9sdgGsllsf5sdYjsts8sjh23sjhPTRksdk8a4G/../../../etc/shadow">...</iframe>

So, the administrator will think- this URI scheme will show b.com's permitted file in iframe. But, actually it will show web server's own /etc/shadow file.

A Proof-of-Concept (PoC) is a working demonstration; this is a partial description. Have you tried it? When hosted on a website the frame will be blank because file:// urls are not allowed. It will not show the shadow file.

If you downloaded the page and opened it as a local file it will show your own shadow file, not anyone else's. Not a vulnerability.

This bug can be used with 'https' too.
https://youtube.com/channel/entertainment/blockbuster/episode/new/../../../../../../@file://google.com/form/file/e2dsf4/../../../../../../etc/passwd

Coalescing is according to the URL spec; Chrome does that too: https://url.spec.whatwg.org/#ref-for-double-dot-path-segment%E2%91%A1

So, an attacker can send the below URL to victims and redirect them to their own cahannel- ...
Victim will think- it is intended channel by looking at the beginner part of the URL. This will happen because browser is path traversing by '../../' signs.

the "@file:" is doing nothing in there. If anything it makes the URL look strange and suspicious. Regardless, people should never trust what a link "looks like" because they can always be spoofed on a web page. The only thing that matters is the URL at the final destination after any hidden redirects on the web whose addresses users never even see.

It looks like bug 1507354 (and bug 376502) cover the fact that we ignore the host part instead of issuing appropriate errors. The rest appears to be working correctly and is not a vulnerability.

Since this bug has gotten quite messy and has now brought up two or three different topics, please create a new bug if you come up with a working PoC. Attach the PoC as an HTML file to the new bug.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
Group: dom-core-security
Flags: sec-bounty? → sec-bounty-
You need to log in before you can comment on or make changes to this bug.