3 ms·

Quoted exactly right, it will not be exploitable. However, this amounts to declaring which input is disallowed, generally not a good idea. It is preferrable to

Quoted exactly right, it will not be exploitable. However, this amounts to declaring which input is disallowed, generally not a good idea. It is preferrable to declare which input is allowed. In this case, matters are worse because without knowing which shell we are running under and which cat we are executing it is impossible to know the complete list of dangerous characters. (In fact, if some sloppy sysadmin have a dot in the search path, the cat binary might even be attacker uploaded.) (The fact that cat is even in there is of course doubly insane. They start an extra process just to make reading the data slightly more complicated.)

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.

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.