On 2016-03-30 16:35, Jacob Champion wrote:
Sorry, but that is not a good approach. You must assume that a local
attacker calls suexec directly and passes arguments of his liking.
That is the attack vector that suexec's rather annoying restrictions
try to avoid.
Checking my own understanding... so if an attacker is able to make
arbitrary calls to suexec as the httpd user (which requires another
vulnerability to begin with) then with this patch, they are able to
execute any scripts in the DocumentRoot as any user. Whereas before
they
would have been limited to running scripts only as their owners. Is
that
correct?
Yes, it's a plausible exploit.
Other possible issues, not necessarily security-related:
- It looks like the args passed to execv[e]() begin with the original
argv[5] (the trusted group name) instead of the original argv[3] (the
command to execute).
I was quite careful to add the new arguments to the end. That way,
suexec can tell the difference between the new and old syntax
by the number of arguments.
- There is also a compatibility change for suexec itself:
suexec target_uname target_gname cmd arg1 arg2 arg3
will now interpret "arg1" and "arg2" as the trusted user and group,
respectively. I don't know if suexec has any compatibility guarantees
from release to release.
(monttyle, please correct me if I've misread the patch.)
CGI being CGI, you don't really get arg1 arg2 arg3 in practice as I
understand it.
Data is passed into stdin instead.
A third approach from the original IRC discussion was to simply compile
the "trusted" user/group directly into suexec, as another configured
option.
--Jacob
You thought of it first... That's probably what I'll try next.
