So cool to see a big project like curl (big as in getting shipped with everything these days) go the proactive route of communicating technically inherent risk and security-impacting design decisions.
KNOWN RISKS: - Looking too cool while using cURL 😎 - Actually getting what you want from a webpage, with clear messages on what your computer is doing.
Maybe this one, which kind of violates the principle of least surprise (but not a security risk)
> When curl is invoked, it (unless --disable is used) checks for a default config file and uses it if found, even when --config is used. The default config file is checked for in the following places in this order:
> When there is a remote attacker already present in the server, curl cannot protect its operations against mischief.
Does that mean that if I wanted to fetch an URL from a malicious server and write the response to stdout, but the server managed to trick curl into saving it to a file with server-controlled filename, despite the commandline options, that would not be a vulnerability in curl?
When you include the curl copyright information in your tool, this will cause some of your users to write to Daniel when their Internet connection is flaky.
pitch R.
in reply to daniel:// stenberg:// • • •Thibault
in reply to daniel:// stenberg:// • • •- Looking too cool while using cURL 😎
- Actually getting what you want from a webpage, with clear messages on what your computer is doing.
JA
in reply to daniel:// stenberg:// • • •Maybe this one, which kind of violates the principle of least surprise (but not a security risk)
> When curl is invoked, it (unless --disable is used) checks for a default config file and uses it if found, even when --config is used. The default config file is checked for in the following places in this order:
daniel:// stenberg://
in reply to JA • • •JA
in reply to daniel:// stenberg:// • • •Not the config itself, but the behavior.
> even when --config is used
I would've expected user-provided --config will be exclusive
Wolf480pl
in reply to daniel:// stenberg:// • • •> When there is a remote attacker already present in the server, curl cannot protect its operations against mischief.
Does that mean that if I wanted to fetch an URL from a malicious server and write the response to stdout, but the server managed to trick curl into saving it to a file with server-controlled filename, despite the commandline options, that would not be a vulnerability in curl?
daniel:// stenberg://
in reply to Wolf480pl • • •Paul Hoffman
in reply to daniel:// stenberg:// • • •