3 ms·

Honest question. Why not just completely outlaw code like: exec("/bin/sh", "-c", "..."); And its friends? It feels like it does way more harm than it does

Honest question. Why not just completely outlaw code like: exec("/bin/sh", "-c", "..."); And its friends? It feels like it does way more harm than it does good.

peterwwillis 7y ago
Because arbitrary "Thou Shalts" do not prevent security holes. Make a restriction, and hackers will find the cracks around it. The only way to stop them is to fill the cracks, and the only way to find the cracks is to look for them. Now, certainly if there was an exec() replacement that was more secure, you should use that; but banning exec() entirely is doing more harm to functionality than good to security. Particularly, the exec() bug here is one of misunderstanding the security guarantees of interfaces; particularly, that there are none. Not validating inputs is the single most universally known security practice, and yet it wasn't done here. On top of that, not using typed objects further increases potential for attacks. This was just shit security design. exec() had about as much to do with the bug as your brakes have to do with you locking up your wheels when traveling too fast in rain/snow/ice. (that you should have been going slower, not that the brakes are defective)
- ainar-g 7y ago
  I haven't proposed to ban exec entirely. I've proposed to ban exec uses that just sends data into a shell.
  - loeg 7y ago
    When a user runs 'sh -c "foo"' on the command line, how do you think that is executed? Taking a step back, Unix's programming model is heavily influenced by the design requirements of interactive bourne shell. It's hard to outlaw shell-like things without breaking shells.
hedora 7y ago
Sometimes you need to tell something to programmatically spawn a shell: watch bash -c “ps | grep argname” and similar.
JdeBP 7y ago
Because it wasn't what actually did the harm in this case. That was a lack of some kind of "--" delimiter, and not using the Bernstein checkpassword approach. And because there are genuine uses for it. I use it in service ./run programs, for example, where simple tooling is not enough and I want shell script things like variable expansions and conditional operators. The first reason is of particular note because it is two good practices to get used to: employing "--" as the norm; and not passing user credentials around in either environment variables or command-line arguments. (Bernstein checkpassword receives the user credentials as NUL-terminated strings over a pipe.) * https://cr.yp.to/checkpwd/interface.html https://cr.yp.to/checkpwd/interface.html

Honest question. Why not just completely outlaw code like: exec("/bin/sh", "-c", "..."); And its friends? It feels like it does way more harm than it does good.

peterwwillis 7y ago

Because arbitrary "Thou Shalts" do not prevent security holes. Make a restriction, and hackers will find the cracks around it. The only way to stop them is to fill the cracks, and the only way to find the cracks is to look for them. Now, certainly if there was an exec() replacement that was more secure, you should use that; but banning exec() entirely is doing more harm to functionality than good to security. Particularly, the exec() bug here is one of misunderstanding the security guarantees of interfaces; particularly, that there are none. Not validating inputs is the single most universally known security practice, and yet it wasn't done here. On top of that, not using typed objects further increases potential for attacks. This was just shit security design. exec() had about as much to do with the bug as your brakes have to do with you locking up your wheels when traveling too fast in rain/snow/ice. (that you should have been going slower, not that the brakes are defective)

ainar-g 7y ago
I haven't proposed to ban exec entirely. I've proposed to ban exec uses that just sends data into a shell.
- loeg 7y ago
  When a user runs 'sh -c "foo"' on the command line, how do you think that is executed? Taking a step back, Unix's programming model is heavily influenced by the design requirements of interactive bourne shell. It's hard to outlaw shell-like things without breaking shells.

hedora 7y ago

Sometimes you need to tell something to programmatically spawn a shell: watch bash -c “ps | grep argname” and similar.

JdeBP 7y ago

Because it wasn't what actually did the harm in this case. That was a lack of some kind of "--" delimiter, and not using the Bernstein checkpassword approach. And because there are genuine uses for it. I use it in service ./run programs, for example, where simple tooling is not enough and I want shell script things like variable expansions and conditional operators. The first reason is of particular note because it is two good practices to get used to: employing "--" as the norm; and not passing user credentials around in either environment variables or command-line arguments. (Bernstein checkpassword receives the user credentials as NUL-terminated strings over a pipe.) * https://cr.yp.to/checkpwd/interface.html https://cr.yp.to/checkpwd/interface.html