suexec privilege elevation
As per FD list post.. Does this seem valid? FWD MESSAGE Apache suEXEC privilege elevation / information disclosure Discovered by Kingcope/Aug 2013 The suEXEC feature provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server. Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. 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. Normally php and cgi scripts are not allowed to read files with the apache user- id inside a suEXEC configured environment. Take for example this apache owned file and the php script that follows. $ 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. $ cat test.php ?php system(id; cat /etc/testapache); ? When calling the php file using a webbrowser it will show... uid=1002(example) gid=1002(example) groups=1002(example) because the php script is run trough suEXEC. The script will not output the file requested because of a permissions error. Now if we create a .htaccess file with the content... Options Indexes FollowSymLinks and a php script with the content... ?php system(ln -sf / test99.php); symlink(/, test99.php); // try builtin function in case when //system() is blocked ? in the same folder ..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 '/'. A request to test99.php/etc/testapache done with a web browser shows.. voila! read with the apache uid/gid 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 listings without querying suEXEC. It is not possible to write to files in this case. Version notes. Assumed is that all Apache versions are affected by this bug. 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=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=128 -D HTTPD_ROOT=/etc/apache2 -D SUEXEC_BIN=/usr/lib/apache2/suexec -D DEFAULT_PIDLOG=/var/run/apache2.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=mime.types -D SERVER_CONFIG_FILE=apache2.conf ___
Re: suexec privilege elevation
On 08/08/2013 09:24 AM, Nick Edwards wrote: As per FD list post.. Does this seem valid? FWD MESSAGE Apache suEXEC privilege elevation / information disclosure Discovered by Kingcope/Aug 2013 The suEXEC feature provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server. Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. 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. Normally php and cgi scripts are not allowed to read files with the apache user- id inside a suEXEC configured environment. Take for example this apache owned file and the php script that follows. $ 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. $ cat test.php ?php system(id; cat /etc/testapache); ? When calling the php file using a webbrowser it will show... uid=1002(example) gid=1002(example) groups=1002(example) because the php script is run trough suEXEC. The script will not output the file requested because of a permissions error. Now if we create a .htaccess file with the content... Options Indexes FollowSymLinks and a php script with the content... ?php system(ln -sf / test99.php); symlink(/, test99.php); // try builtin function in case when //system() is blocked ? in the same folder ..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 '/'. A request to test99.php/etc/testapache done with a web browser shows.. voila! read with the apache uid/gid 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 listings without querying suEXEC. It is not possible to write to files in this case. Version notes. Assumed is that all Apache versions are affected by this bug. 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=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=128 -D HTTPD_ROOT=/etc/apache2 -D SUEXEC_BIN=/usr/lib/apache2/suexec -D DEFAULT_PIDLOG=/var/run/apache2.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=mime.types -D SERVER_CONFIG_FILE=apache2.conf ___ This is a very well known issue in the shared hosting circles. I don't think anyone should be surprised about that. This attack is known since 2006-2007 and the solution is to prevent the usage of FollowSymlinks and to replace it with SymLinksIfOwnerMatch. The attack has been used even before 2006. Most webhosts either patch their apache servers to map FollowSymlinks to SymLinksIfOwnerMatch or do not allow FollowSymlinks. If you search in the lists archives, you will find quite a few discussions about that. Marian
Re: suexec privilege elevation
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 listings without querying suEXEC. Displaying symlinks and directory listings is not a reason. suEXEC changes the ID for executable content only. This is not executable content, it's content owned and readable by www-data that is symlinked into a web-accessible directory.
htdigest -c inconsistencies
Dear httpd developers My previous attempt [1] to bring your attention to that tiny issue did't really bring a flood of answers. ;) Bug summary: * man says htdigest -c will truncate file. * htdigest -c does not truncate file like it used to, since some time [2]. I can think of 3 options: Option 1: Fix htdigest to revert the regression^Wchange introduced. Patch here. [3] = File truncated as documented Option 2: Acknowledge the change, and fix the documentation. = File created or appended as needed Option 3: Bail out if file exists. This was suggested by some users. This mitigate the risk of data loss, if we consider -c behavior has been in the wild for some time now. = Bail out if file exists Full bug report is here [4]. What do you think should be done? Thank you! [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201202.mbox/%3c201202051352.41527.jmv_...@nirgal.com%3E [2] https://svn.apache.org/viewvc/httpd/httpd/trunk/support/htdigest.c?r1=85063r2=85064 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;filename=564722.diff;att=1;bug=564722 [4] https://issues.apache.org/bugzilla/show_bug.cgi?id=55379