On 03/30/2016 01:49 PM, Stefan Fritsch wrote:
> You are doing the configuration parsing in httpd, and then pass the
> allowed uid/group to suexec as command line arguments.
>
> 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?
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).
- 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.)
> So the config file parsing would have to be done inside suexec, with
> the config file path being compiled into the suexec utility. Of
> course, this would cause some slowdown because suexec would need to
> parse its config file on every request.
>
> A different idea would be to use filesystem xattrs. Maybe check for an
> xattr APACHE_SUEXEC_ALLOWED, and if a file is owned by root and has
> that xattr, suexec would allow to change to the user specified in the
> xattr.
>
> But these two approaches are just ideas. I don't know if they would be
> accepted in httpd.
A third approach from the original IRC discussion was to simply compile
the "trusted" user/group directly into suexec, as another configured option.
--Jacob
