Date: Wed, 2 Jan 2019 20:49:08 +1300 From: Amos Jeffries <squid3@...enet.co.nz> To: oss-security@...ts.openwall.com Subject: Re: wget / chromium: URL metadata and potential password leaks via extended filesystem attributes On 1/01/19 11:15 pm, Hanno Böck wrote: > Hi, > > Via some twitter discussions  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]/). FYI: Since RFC 2616 the userinfo@ portion of generic URI has been deprecated in http: and https: scheme URLs. The current standard RFC 7230 added a requirement of UI tools to treat such URLs as errors instead of fetching. Agents may still choose to accept/tolerate URLs with userinfo@, but are then required to erase and ignore the userinfo@ octets before any other processing of the URL. It has this status due to the well-known security problems with credentials existing in URL. So IMO this reason would be CVE-worthy if the userinfo@ was preserved in that stored form of the URLs. But if they were filtering it away this reason would not be relevant. > * Sometimes URLs may contain secret tokens, e.g. private file shares on > a file hosting service. This is a bigger security problem IMHO. It is created by developers choice to place secrets in the URL and has no real solution other than stopping people doing that behaviour entirely. UI applications cannot be reasonably expected to know every possible combination of octets that are secrets. > * In general storing metadata at unexpected places should be avoided. > That depends on ones expectations. In HTTP environment the URL is the objects canonical name. That thing humans call a "filename" is the metadata which may or may not exist. In FS terms the extended attributes *are* the expected place to store metadata of an object. That is the purpose of the extensions. I expect wget accepted the CVE and added option to control the behaviour since that tool can be used to store D/L object anywhere in the FS. Chrome on the other hand uses FS areas clearly dedicated to D/L object storage. So object in that area should be fully expected to possibly be associated with metadata *somewhere* containing secrets, the closer that somewhere is tied to the FS object the better its security properties. For example; the extended attributes are erased when an object in Downloads/ folder/directory is deleted manually by non-Chrome FS tools. This is better for security than some separate cache of metadata holding onto the URL + secrets for possibly years after the object is deleted by a user. AYJ Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.