[brynet]

It is indeed another security mitigation, any potential attack payload will need to do more work and hence require more code.

In fact, most programs will not need the exec promise in which case any attempt to call execv(3)..

Abort trap (core dumped)

If you think about the semantics of execv(3), it needs a path to an existing executable. So an attacker will need to know of one in advance, or write one out to disk beforehand.. oh but--

Abort trap (core dumped)

The exploited process pledged "stdio rpath proc exec" and cannot write to arbitrary files. Hmm. Bummer.

[amluto]

> If you think about the semantics of execv(3), it needs a path to an existing executable. So an attacker will need to know of one in advance, or write one out to disk beforehand.. oh but--

/bin/sh, perhaps? It's harder to pass in machine code, but I bet there's a way. /bin/sh -c "echo -e shellcode_here >/tmp/foo; chmod 700 /tmp/foo; /tmp/foo" seems plausible to me.

[mbrock]

Well, binary shellcode often has the sole purpose of providing shell access, so if you can just exec /bin/sh then that job is already done...

[brynet]

You're right, of course. If you promise exec, you should certainly expect someone will find a way to use it.