3 ms·

Thanks > matters are worse because without knowing which shell we are running under The shell in exec can be configured, it's /bin/sh by default but of course

by tomxor 8y ago

Thanks > matters are worse because without knowing which shell we are running under The shell in exec can be configured, it's /bin/sh by default but of course this is linked to all kinds of different things on different OS, ubuntu links to dash, used to be bash, FreeBSD has a "proper" sh. I suppose if going through a shell was somehow necessary you could try to be more secure by specifying a absolute path to a shell but... > In fact, if some sloppy sysadmin have a dot in the search path, the cat binary might even be attacker uploaded. :P I feel like it's game over at that point, is there really any point in worrying about library security when the $PATH has been effectively hijacked?

xorcist 8y ago
> is there really any point in worrying about library security when the $PATH has been effectively hijacked? Well, there might be legitimate (although somewhat misguided) reasons for someone to do that. People routinely do similar things in dev environments all the time. I can absolutely see how it could reach production. If you don't expect your web app to launch shell scripts you might not even think about it. It's the small things, which in themselves might not be serious or even noteworthy, which compound together to deliver the nasty surprises.