Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2018-20483 aka user.xdg.origin.url #2766

Closed
bsclifton opened this issue Dec 31, 2018 · 12 comments · Fixed by brave/brave-core#2100
Closed

CVE-2018-20483 aka user.xdg.origin.url #2766

bsclifton opened this issue Dec 31, 2018 · 12 comments · Fixed by brave/brave-core#2100

Comments

@bsclifton
Copy link
Member

Description

Carried over from brave/browser-laptop#15344

Downloaded files are saving URLs from which are downloaded into «user.xdg.origin.url» or «user.xdg.referrer.url»

Steps to Reproduce

  1. Download file
  2. Read with getfattr
  3. Check if file contain location from which was downloaded

Actual result:

Expected result:

Reproduces how often:

Brave version (brave://version info)

Version 0.58.17 Chromium: 71.0.3578.98 (Official Build) (64-bit)

Reproducible on current release:

  • Does it reproduce on brave-browser dev/beta builds?

Website problems only:

  • Does the issue resolve itself when disabling Brave Shields?
  • Is the issue reproducible on the latest version of Chrome?

Additional Information

@rastislavcore
Copy link

I want add to discussion - this is very important especially for TOR in Brave browser.

@NejcZdovc NejcZdovc added this to the 1.x Backlog milestone Jan 2, 2019
@diracdeltas
Copy link
Member

Has anyone verified this issue repros in the new version of Brave?

@fmarier
Copy link
Member

fmarier commented Jan 29, 2019

I can confirm that the current Linux version of brave-core is affected (Version 0.58.21 Chromium: 71.0.3578.98 (Official Build) (64-bit)):

  1. Open a normal browsing window
  2. Go to https://pypi.org/project/canadian-ham-exam/#files
  3. Download canadian-ham-exam-0.2.0.tar.gz
  4. Use getfattr (part of the attr package on Debian/Ubuntu) to extract the metadata:
$ getfattr canadian-ham-exam-0.2.0.tar.gz 
# file: canadian-ham-exam-0.2.0.tar.gz
user.xdg.origin.url
user.xdg.referrer.url

$ getfattr -n user.xdg.origin.url canadian-ham-exam-0.2.0.tar.gz 
# file: canadian-ham-exam-0.2.0.tar.gz
user.xdg.origin.url="https://files.pythonhosted.org/packages/d9/0a/d3d1290794660b7e49efe1339a3dc57e3c9b82ac7641595a485691f51ee2/canadian-ham-exam-0.2.0.tar.gz"

$ getfattr -n user.xdg.referrer.url canadian-ham-exam-0.2.0.tar.gz 
# file: canadian-ham-exam-0.2.0.tar.gz
user.xdg.referrer.url="https://files.pythonhosted.org/"

Note that this metadata is not present when the file is downloaded in:

  • a guest window
  • a private window
  • a Tor private window

@fmarier
Copy link
Member

fmarier commented Jan 29, 2019

It looks pretty easy to patch out.

The extended attributes are defined here and then set in this function.

@fmarier
Copy link
Member

fmarier commented Jan 29, 2019

The URL and referrer are explicitly omitted when the user is in an off-the-record window.

This is apparently from a Windows feature called the Mark of the Web which allows some software (e.g. MS Office, Windows Explorer) to treat these files are less trustworthy and display extra warnings or apply extra restrictions when they are opened.

@fmarier
Copy link
Member

fmarier commented Jan 29, 2019

Note: Firefox doesn't set any Linux extended attributes on downloads in normal mode.

@rebron rebron removed this from the 1.x Backlog milestone Feb 7, 2019
@diracdeltas diracdeltas added the priority/P4 Planned work. We expect to get to it "soon". label Feb 20, 2019
@fmarier
Copy link
Member

fmarier commented Feb 20, 2019

@diracdeltas suggested looking into spoofing the value of the URL to see if we can get the benefits of the Mark of the Web without having the exact URL in there.

We could try setting the URL to http://example.com and then remove the referrer.

@fmarier
Copy link
Member

fmarier commented Mar 21, 2019

I discussed this bug with someone who works on Windows Defender and he told me that the Mark of the Web is very important since A/V products will treat files from the Web as suspicious and do extra checks on them.

Having the real URL and referrer means that these products can do additional reputation checks against the URLs that are included, however, they will still scan the files if the original URL has been scrubbed and replaced with a bogus one.

What I therefore propose is to:

  • remove the referrer URL
  • replace the URL with a hard-coded one (about:internet)

In addition, since we would no longer be leaking the original URL, we could also mark files that are downloaded in Private windows (but not Tor windows), which would be a security win.

@fmarier fmarier self-assigned this Mar 21, 2019
@fmarier
Copy link
Member

fmarier commented Mar 22, 2019

I did some more testing on Firefox for Windows and found that they add the alternate NTFS data stream with the same content in normal and private modes (and in Tor Browser Bundle):

[ZoneTransfer]
ZoneId=3

Therefore they never leak the URLs at all.

In contrast, Brave/Chromium on Windows will put the following in the NTFS data stream in normal windows:

[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://files.pythonhosted.org/
HostUrl=https://files.pythonhosted.org/packages/d9/0a/d3d1290794660b7e49efe1339a3dc57e3c9b82ac7641595a485691f51ee2/canadian-ham-exam-0.2.0.tar.gz

and the following in Private and Tor windows:

[ZoneTransfer]
ZoneId=3
HostUrl=about:internet

@fmarier
Copy link
Member

fmarier commented Mar 22, 2019

It turns out that this metadata has been removed from Linux builds in Chromium 74.0.3691.0. Therefore the only platforms that need to be fixed (in normal mode) are Windows and macOS.

fmarier added a commit to fmarier/brave-core that referenced this issue Mar 27, 2019
This fixes brave/brave-browser#2766 by making the download
metadata the same whether it's coming from normal, private or Tor
windows.
fmarier added a commit to brave/brave-core that referenced this issue Mar 28, 2019
This fixes brave/brave-browser#2766 by making the download
metadata the same whether it's coming from normal, private or Tor
windows.
fmarier added a commit to brave/brave-core that referenced this issue Mar 29, 2019
This fixes brave/brave-browser#2766 by making the download
metadata the same whether it's coming from normal, private or Tor
windows.
@fmarier
Copy link
Member

fmarier commented Apr 4, 2019

I tested the fix for this on Windows, Mac and Linux using Nightly 0.65.16 and following the test plan in brave/brave-core#2100 (comment).

@LaurenWags
Copy link
Member

LaurenWags commented May 17, 2019

Verified passed with

Brave 0.65.95 Chromium: 74.0.3729.131 (Official Build) beta(64-bit)
Revision 518a41c1fa7ce1c8bb5e22346e82e42b4d76a96f-refs/branch-heads/3729@{#954}
OS Mac OS X

Verification passed on

Brave 0.65.97 Chromium: 74.0.3729.131 (Official Build) beta(64-bit)
Revision 518a41c1fa7ce1c8bb5e22346e82e42b4d76a96f-refs/branch-heads/3729@{#954}
OS Ubuntu 18.04 LTS

Verification passed on

Brave 0.65.98 Chromium: 74.0.3729.131 (Official Build) beta (64-bit)
Revision 518a41c1fa7ce1c8bb5e22346e82e42b4d76a96f-refs/branch-heads/3729@{#954}
OS Windows 10 OS Build 17134.523

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment