Re: Feedback needed: suexec different-owner patch

[mo...@heavyspace.ca]

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.

Re: Feedback needed: suexec different-owner patch

[Jacob Champion <ch...@gmail.com>]

On 04/02/2016 12:56 PM, Stefan Fritsch wrote:
> If suexec allowed to suid to a user different than the owner of a 
> script, on that server it would allow any local user to execute any 
> script as any other user. Even if suexec checked that the script is 
> owned by a special "trusted" user, it would still allow to execute 
> that script as any user, without any "opt-in" necessary by the target 
> user.

Ah, this finally made it click for me.

In the case where only the trusted-owner CGI script is compromised (e.g.
an arbitrary code execution vuln), this proposal makes things better,
since the attacker can at least be denied access to the disk. But if
httpd is compromised, it makes things worse, since the attacker can now
run the trusted-owner script as any non-system user. And if both httpd
and the trusted-owner script are compromised, this proposal makes things
*much* worse: an attacker can now run arbitrary code as any non-system user.

Thanks for your feedback on this. Your xattrs suggestion seems like it
might solve the two negative cases, but it uses a much more obscure
(IMO) mechanism to operate... Likewise, having suexec parse a separate
configuration file seems like a lot of complexity to add.

> BTW, using the immutable flag (which can only be done by root) on the 
> scripts is a work-around for your problem that does not involve 
> modifying suexec.

Good point, though I don't think it can be used for the proposed use
case (which was for the trusted user to be able to regularly maintain
the scripts).

--Jacob

Re: Feedback needed: suexec different-owner patch

[Stefan Fritsch <sf...@sfritsch.de>]

On Friday 01 April 2016 14:03:12, monttyle@heavyspace.ca wrote:
> 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. Without the patch, a user would have to "opt-in" to using suexec 
by putting a executable file in one of the paths allowed by suexec. 
With the patch, suexec would allow the apache user to become every 
other user, just by being installed.

Of course people may modify suexec to suit their use cases and the 
situation on their servers. But for a suexec variant that is shipped 
by apache by default, it is important that it does not allow local 
privileg escalation, not in any situation.

So imagine a multi-user server where users are allowed to execute 
cgi/php scripts as httpd run user in their ~/public_html folder. This 
is not a very smart setup, but I am 100% sure that such setups exist. 
If suexec allowed to suid to a user different than the owner of a 
script, on that server it would allow any local user to execute any 
script as any other user. Even if suexec checked that the script is 
owned by a special "trusted" user, it would still allow to execute 
that script as any user, without any "opt-in" necessary by the target 
user.

> Yes, it's a plausible exploit.
> 

> > A third approach from the original IRC discussion was to simply
> > compile the "trusted" user/group directly into suexec, as another
> > configured option.

> You thought of it first...  That's probably what I'll try next.

As outlined above, I don't think this would be appropriate to include 
in the suexec shipped with apache httpd.


BTW, using the immutable flag (which can only be done by root) on the 
scripts is a work-around for your problem that does not involve 
modifying suexec.