When using -J -O options on curl command line tool and a server responding with a header that is using Content-Disposition to provide a filename, existing local file will be overwritten if the file is non-readable by the current user, but file is writable by the current user.
Curl contains protection to prevent the overwrite, but protection code is using the file's readability permission to check for its existence. So protection will be bypassed in this case, as it is only writable by the user.
Issue was discovered after review of CVE-2020-8177 description. I was curious how the Content-Disposition feature and prevention of file overwrite worked. While reviewing the code around that feature noted that the existence of the file is checked via being able to read the file. So what happens if the file is not readable, but writable!?!
Why would a system have a file that is writable only, for sensitive information that must be collected by a particular user, but must not be viewable by that user. Certain logs or audit trails or privacy related files or security related files, might have such restrictions.
Additionally, and in an extreme example, code as written is susceptible to Race Condition as the file existence check and file write are done with two distinct fopen() calls in the tool_create_output_file() in tool_cb_wrt.c file. Data lose possible if parallel write operations performed on the same file via two curl processes, or even some other process (malicious or not) acting/interfering on the same file.
One way to fix the issue robustly (check for file existence and create file in one operation) would be to use the open() to create the file while using safe options (such as O_CREAT | O_WRONLY | O_EXCL), as is shown in one of the solutions in this stackoverflow posting (see posting by "Dan Lenski", for example):