You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Lukas Erlacher <er...@in.tum.de> on 2016/10/20 09:06:28 UTC

[users@httpd] mod_cgid socket permissions

Hello,

I am running an apache 2.4 server (2.4.18-2ubuntu3.1) on Ubuntu 16.04 
with mod_userdir, mod_suexec_custom, mod_cgid and php5.6-cgi.

Users can place arbitrary documents and scripts in their userdirs and 
are not considered trusted, so should not be able to interfere with 
anything except their own scripts and should not be able to do anything 
other than have apache execute their scripts with their

https://httpd.apache.org/docs/2.4/mod/mod_cgid.html#scriptsock says:
> The socket will be opened using the permissions of the user who starts Apache (usually root). To maintain the security of communications with CGI scripts, it is important that no other user has permission to write in the directory where the socket is located.

To make CGID work with suexec+userdir, I've had to change the socket to 
make it group-owned by www-data and with g+w set:

> me@box:~$ ls -al /var/run/apache2/
> total 4
> drwxr-xr-x  2 root     root       80 Oct 20 09:09 .
> drwxr-xr-x 25 root     root     1000 Oct 20 10:38 ..
> -rw-r--r--  1 root     root        5 Oct 20 09:09 apache2.pid
> srwx-w----  1 www-data www-data    0 Oct 20 09:09 cgisock.9822

I hacked up the init script to perform this, by adding the following to 
apache_wait_start:

> for sockfile in /var/run/apache2/cgisock.*; do
>         if [ -S "$sockfile" ]; then
>                 chown www-data:www-data /var/run/apache2/cgisock.*
>                 chmod g+w /var/run/apache2/cgisock.*
>                 break
>         fi
> done

This works because suexec apparently retains the www-data group membership.

(Here's the output of a php script that echos posix_getuid() and runs 
system('id -a'):

> 31524
> uid=31524(erlacher) gid=20909(tumuser) groups=20909(tumuser),0(root),4(adm),33(www-data),108(syslog),5177(sambarbg),9044(rbg),14777(ljfs),16693(desktop)

Ignore the "root" group, that's part of my groups. Of course it would be 
nice to have suexec drop groups, but that's not a feature that exists...
)

Now, getting back to the statement in the apache docs: Is this a 
security violation / vulnerability? What can an attacker do with that 
socket other than execute arbitrary programs on the machine using their 
own permissions (plus www-data group)? They can already do that by 
virtue of being able to place arbitrary cgi scripts in their userdirs.

Thank you for any thoughts or pointers!

Best regards,
Luke


Re: [users@httpd] mod_cgid socket permissions

Posted by Eric Covener <co...@gmail.com>.
On Thu, Oct 20, 2016 at 9:53 AM, Lukas Erlacher <er...@in.tum.de> wrote:
> I'm now entirely at a loss as to what's going on on my webserver. Does
> mod_userdir implicitly enable suexec? Did the Ubuntu maintainers screw up
> and compile it in with apache?

It doesn't implicitly enable it, but it does tell mod_cgid that an
identity is associated with the current request (IIUC) and cgid will
eventually run it under suexec, if suexec is enabled.

I am not sure what's going on w/ the rest of your env though re: mixed
results about whether suexec is loaded.

-- 
Eric Covener
covener@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] mod_cgid socket permissions

Posted by Lukas Erlacher <er...@in.tum.de>.
So this is weird...

In response to

> I didn't see any info mod_suexec_custom, but suexec
> should not be running until long after the socket communication
> between httpd and cgid is over.   What talks to cgid in this case that
> doesn't have a www-data userid?

I was going to tell you "Well, if I don't chown the server, the CGI 
invocation fails with

> (13)Permission denied: [client 131.159.43.223:34136] AH01257: unable to connect to cgi daemon after multiple tries

but if I do it doesn't", and checked that on the server, and saw I had 
accidentally left two modules enabled left over from earlier 
experimentation (ruid2, fastcgi), so I disabled them and the error went 
away.

In trying to debug it further, I also disabled suexec just to see 
scripts being executed by the www-data user... but they aren't.

Here's apache2ctl -M:

> me@box:~$ sudo apache2ctl -M
> Loaded Modules:
>  core_module (static)
>  so_module (static)
>  watchdog_module (static)
>  http_module (static)
>  log_config_module (static)
>  logio_module (static)
>  version_module (static)
>  unixd_module (static)
>  access_compat_module (shared)
>  actions_module (shared)
>  alias_module (shared)
>  auth_basic_module (shared)
>  authn_core_module (shared)
>  authn_file_module (shared)
>  authz_core_module (shared)
>  authz_host_module (shared)
>  authz_user_module (shared)
>  autoindex_module (shared)
>  cgid_module (shared)
>  deflate_module (shared)
>  dir_module (shared)
>  env_module (shared)
>  ext_filter_module (shared)
>  filter_module (shared)
>  mime_module (shared)
>  mpm_prefork_module (shared)
>  negotiation_module (shared)
>  rewrite_module (shared)
>  setenvif_module (shared)
>  socache_shmcb_module (shared)
>  ssl_module (shared)
>  status_module (shared)
>  userdir_module (shared)

I'm now entirely at a loss as to what's going on on my webserver. Does 
mod_userdir implicitly enable suexec? Did the Ubuntu maintainers screw 
up and compile it in with apache?

suexec.log is still logging suexec invocations

> ==> /var/log/apache2/suexec.log <==
> [2016-10-20 15:53:32]: uid: (31524/erlacher) gid: (20909/tumuser) cmd: foo-data-x.php

, but restarting apache brings brings up only

> ==> /var/log/apache2/error.log <==
> [Thu Oct 20 15:49:47.791148 2016] [mpm_prefork:notice] [pid 27800] AH00169: caught SIGTERM, shutting down
> [Thu Oct 20 15:49:47.989104 2016] [mpm_prefork:notice] [pid 27889] AH00163: Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2g configured -- resuming normal operations
> [Thu Oct 20 15:49:47.989320 2016] [core:notice] [pid 27889] AH00094: Command line: '/usr/sbin/apache2'

and not the suexec startup message:

> [Thu Oct 20 15:26:40.809958 2016] [suexec:notice] [pid 26788] AH01232: suEXEC mechanism enabled (wrapper: /usr/lib/apache2/suexec)

Is my webserver haunted?

Best,
Luke

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] mod_cgid socket permissions

Posted by Eric Covener <co...@gmail.com>.
On Thu, Oct 20, 2016 at 5:06 AM, Lukas Erlacher <er...@in.tum.de> wrote:
> Now, getting back to the statement in the apache docs: Is this a security
> violation / vulnerability? What can an attacker do with that socket other
> than execute arbitrary programs on the machine using their own permissions
> (plus www-data group)? They can already do that by virtue of being able to
> place arbitrary cgi scripts in their userdirs.

Presumably they could block your CGI scripts, or ask mod_cgid to run
scripts outside of those reachable by any URI.

Note that mod_cgid already chown's the socket to the configured
userid, but not the primary group. This allows the httpd children to
write to it.  I didn't see any info mod_suexec_custom, but suexec
should not be running until long after the socket communication
between httpd and cgid is over.   What talks to cgid in this case that
doesn't have a www-data userid?


-- 
Eric Covener
covener@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org