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:
- wget / chromium: URL metadata and potential password leaks via extended filesystem attributes Hanno Böck (Jan 01)