Add a New Comment (Rich Markup)
Comment Type & Canned Response: None None No Response. Close
( Jump to the original submission )
Looking at the curl patch, it seems that it restricts all Authorization headers, even manually added ones, unless the option is set. That seems like the right way to go to me.
https://github.com/curl/curl/commit/af32cd3859336ab.patch
How about adding a warning in the documentation and/or man page ? That feels like a simple solution :
- RFC is still respected, there are no change in behavior or added options - Users have a way to be warned that manually adding Authenticate headers (or any headers with secret data) may be leaked on 30x response, and thus should be manipulated with care.
Is there any news on this issue?
The Authorization is not special when set manually (someone else may want to use a different header to send private information that should removed on redirection).
So a new option may allow detailed control over how often each manually set header can be redirected.
Or simply a leading flag like
--header "0,Authorization: ..." # don't set in redirections --header "1,Authorization: ..." # set in redirections (default)
A CVE seems to have been assigned :
https://nvd.nist.gov/vuln/detail/CVE-2021-31879
https://mail.gnu.org/archive/html/bug-wget/2021-02/msg00002.html
Hi, I originally reported this issue. The only reason I reported it as a security issue was due to it matching the cve for curl. I was originally going to report it as a bug, due to the fact it breaks pulling down files from a generated(redirected) presigned aws s3 download link.
I use the header option because I'd prefer not to store, and/or use raw passwords on a system. Storing the auth header isn't secure by no means, but it's better than raw username and password stored in a file. But as it stands I have to use raw username and password to be able to pull down files from a presigned s3 link if using wget. This is because when using the auth header it is forwarded to aws, and aws throws a "ERROR 400: Bad Request" every time.
Would it be possible to add a parameter to not forward the auth header on redirects, or make it default to not forwarding unless you pass a parameter telling it to forward the header like curl implemented?
I agree with Tim here that this is not a security issue.
Wget provides an option to correctly use the Authorization header. If the user chooses to otherwise coerce Wget into doing something different, we should not stop them from doing so.
Using `--header=Authorization: ds` means that the user is explicitly opting to send the header everytime rather than only to a specific domain.
On your request I'm making this issue public.
If this isn't considered a security issue, would it be feasible to publish it for possible discussion ?
I do not really think header manipulation necessarily involves expert level knowledge with security in mind.
I do not think that the current behaviour is likely to be abused with malicious intent. However, what can be considered worrying is the case of "cloud services", where you authenticate to Server A, which redirects you to cloud server B with a signed token. Even if both A and B are considered safe, there is still no reason for B, possibly hosted by some random cloud service on the other side of the world, to receive credentials meant for A. Even though B is probably trusted, it still accidentally receives credentials not meant to be sent there.
curl resolved this by defaulting to `Authorization` not being forwarded unless CURLOPT_UNRESTRICTED_AUTH flag is set (https://curl.haxx.se/docs/CVE-2018-1000007.html)
If the behavior is not going to be changed because undefined in RFC, then a warning in the documentation & man page could be written, to ensure that people using an `Authorization` header are aware that the server may return a redirect.
Manually crafting a header means there is some expert level knowledge at work. A person who really knows what she wants. This person should be aware of dangers introduced by redirections (and likely looks up --max-redirect if wanted).
IMO, not a bug but a feature for "power" users.
Except there is a specification (RFC) that doesn't allow Authentication: header in redirections. In this case I would like to make wget follow that.
We should make sure that Wget2 removes the Authentication: header on redirects (have the same behavior as Wget1.x).
wget is vulnerable to a flaw similar to curl's CVE-2018-1000007 (https://access.redhat.com/security/cve/cve-2018-1000007)
Here's the description : -> if you use wget with the regular --user & --password leading to a Basic authentication, and that the server returns a redirect, wget will correctly remove the `Authorization` header before following the redirect query -> However, if you add the basic authentication manually in the header (e.g.: `Authorization: Basic <credentials>`), wget will NOT clean that up before the redirect. Which means that 2nd server will receive unexpected credentials. Filling up the `Authorization` header is likely to happen when you use wget in a script, or if you want to avoid the first request created by the `--user` option.
The leak could be an issue in certain situation (e.g.: more and more services being in "the cloud", redirect to other servers after authentication is, I believe, not uncommon).
No CVE has been assigned yet, I was first hoping to get you feedback & plan.
This was originally reported by Ryan Blakley of Red Hat.
Best regards,
Cedric
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 3 latest changes.
Copyright © 2022 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.9