oss-sec mailing list archives

wget / chromium: URL metadata and potential password leaks via extended filesystem attributes


From: Hanno Böck <hanno () hboeck de>
Date: Tue, 1 Jan 2019 11:15:40 +0100

Hi,

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.

[1] https://twitter.com/gynvael/status/1077671412847046657
[2] https://lists.gnu.org/archive/html/bug-wget/2018-12/msg00034.html

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno () hboeck de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


Current thread: