This is hugely misleading. This does not expose an “arbitrary command execution” in wget, or did I miss something?
This just says that wget by default will both 1) follow 300 redirects and 2) save the requested file in the current dir without renaming it. This is both intended behavior and something you know when you invoke wget. As a side note, curl does not do either of those things, but if it did it would be just as “vulnerable” as wget.
Lastly, wget is noisy even without -v and you’ll see the filename of the downloaded file in the progress output.
This alleged security fail is similar in a way to the complaint about Chromium not making a bigger noise when pinned certs are bypassed by a local root cert. At some point we have to give responsibility back to the user of the software instead of making assumptions about what’s really best for them.
This is hugely misleading. This does not expose an “arbitrary command execution” in wget, or did I miss something?
This just says that wget by default will both 1) follow 300 redirects and 2) save the requested file in the current dir without renaming it.
You got that last part backwards; i.e. the file is renamed to whatever a malicious server chooses—not what the user expects.
This alleged security fail is similar in a way to the complaint about Chromium not making a bigger noise when pinned certs are bypassed by a local root cert.
…In the sense that both are legitimate security issues?
This seems functionally identical to standard browser behavior when using the content-disposition header.
If you want to control the output name, use a flag to specify the output file name.
This is hugely misleading. This does not expose an “arbitrary command execution” in wget, or did I miss something?
This just says that wget by default will both 1) follow 300 redirects and 2) save the requested file in the current dir without renaming it. This is both intended behavior and something you know when you invoke wget. As a side note, curl does not do either of those things, but if it did it would be just as “vulnerable” as wget.
Lastly, wget is noisy even without -v and you’ll see the filename of the downloaded file in the progress output.
This alleged security fail is similar in a way to the complaint about Chromium not making a bigger noise when pinned certs are bypassed by a local root cert. At some point we have to give responsibility back to the user of the software instead of making assumptions about what’s really best for them.
You got that last part backwards; i.e. the file is renamed to whatever a malicious server chooses—not what the user expects.
…In the sense that both are legitimate security issues?