You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix is simple: just lock the file where Wget will write the downloaded file. A safe programming approach would be to use O_CREAT | O_EXCL when creating a file
This approach ensures that the file is created and locked atomically. If the file already exists (even as a symlink), the operation will fail.
Best,
The text was updated successfully, but these errors were encountered:
I think Wget should enable atomic creation and locking by default, and we could add an option to disable this behavior (for backward compatibility with edge cases where atomicity isn’t necessary).
So my new proposed behavior would be:
Default: Secure file creation (atomic + locked).
Optional: --no-atomic or --insecure-write for legacy use cases.
This vulnerability:
https://nvd.nist.gov/vuln/detail/CVE-2004-2014
was reported 20 years ago. It is still working on Wget 1.21.4
Here original details:
https://bugs.gentoo.org/51365
Fix is simple: just lock the file where Wget will write the downloaded file. A safe programming approach would be to use O_CREAT | O_EXCL when creating a file
This approach ensures that the file is created and locked atomically. If the file already exists (even as a symlink), the operation will fail.
Best,
The text was updated successfully, but these errors were encountered: