3 ms·

Since you're here... >Do not shell out to arbitrary commands in the standard library for any reason. If an attacker can somehow run code on a server with a V b

by dTal 6y ago

Since you're here... >Do not shell out to arbitrary commands in the standard library for any reason. If an attacker can somehow run code on a server with a V binary that uses the download_file function, they can replace curl with a malicious binary that is able to do anything the attacker wants. I don't understand this threat model. If an attacker is in a position to replace /usr/bin/curl with a malicious binary, surely you're already pwned? And surely an attacker could just as easily switch out libcurl.so as the curl binary? I just can't make sense of any threat model which treats the OS as untrusted.

xena 6y ago
As written it's it won't just call /usr/bin/curl, but the first curl in $PATH. Not to mention just hardcoding /usr/bin/curl isn't portable (Android/NixOS don't have a /usr/bin like you expect). Also take a look at this: https://christine.website/blog/OVE-20190623-0001 https://christine.website/blog/OVE-20190623-0001
a1369209993 6y ago
Many computers are misconfigured to include "." (the current working directory at the time of execve) in PATH, which allows a trivial privilege escalation and/or native code execution for any attacker that can write a executable file named "curl" in any directory that the target process can be convinced to cd into. Shelling out also means the process will unexpectedly stop working if /usr/bin/curl disappears (or wasn't installed in the first place), whereas that's a known and expected issue for libcurl.so and there are established tools (eg `ldd /bin/program`) for tracking such dependencies.