Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 Jan 2019 11:15:40 +0100
From: Hanno Böck <>
Subject: wget / chromium: URL metadata and potential password leaks via
 extended filesystem attributes


Via some twitter discussions [1] I recently learned about a worrying
behavior of wget and Chromium / Chrome.

The URL of downloads gets stored via filesystem attributes on systems
that support Unix extended attributes.

You can see these attributes on Linux systems by running
getfattr -d [filename]
(The download URL is stored in a variable "user.xdg.origin.url")

This is worrying for a number of reasons:
* In combination with HTTP authentication a username and password can
  be part of the URL (HTTP authentication can be accessed via an URL of
  the form https://[username]:[password]@[hostname]/).
* Sometimes URLs may contain secret tokens, e.g. private file shares on
  a file hosting service.
* In general storing metadata at unexpected places should be avoided.

What's limiting this issue a bit is that tar does not by default store
these extended attributes. I haven't tested other archiving tools.

wget has released an update (1.20.1) and CVE-2018-20483 got assigned
[2]. It changes the default behavior: extended attributes only get
stored if a user explicitly enables it with a parameter. I believe this
is a good solution.

It's been reported to Chrome as well. (Currently private bug report,
but given this was already discussed on Twitter I don't think this
needs to be kept confidential.)

It may be worthwhile checking if other tools share this behavior.


Hanno Böck

GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.