http://permalink.gmane.org/gmane.comp.php.suphp.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.php.suphp.general/1150 <pre>Hi! Attached, a small fix for configure.ac to enable compilation on Apache 2.4. I have tested this myself, and am runnign apache 2.4 with suphp successfully. Aki Tuomi _______________________________________________ suPHP mailing list suPHP-qhrM8SXbD5JCREYaNQg7v0EOCMrvLtNR&lt; at &gt;public.gmane.org https://lists.marsching.com/mailman/listinfo/suphp </pre> Aki Tuomi 2013-05-20T17:37:26 http://permalink.gmane.org/gmane.comp.php.suphp.general/1149 <pre>Hi, I just released suPHP 0.7.2, which fixes a security issue present in suPHP 0.7.0 and 0.7.1. The bug existed in the routine handling the display of PHP source files: When the suPHP_PHPPath was set, mod_suphp would use the specified PHP executable to pretty-print PHP source files (MIME type x-httpd-php-source or application/x-httpd-php-source). However, it would not sanitize the environment. Thus a user that was allowed to use the SetEnv directive in a .htaccess file (AllowOverride FileInfo) could make PHP load a malicious configuration file (e.g. loading malicious extensions). As the PHP process for highlighting the source file was run with the privileges of the user Apache HTTPd was running as, a local attacker could probably execute arbitrary code with the privileges of this user. This update fixes the problem by cleaning the environment before calling the PHP executable for printing the source code. I want to thank John Lightsey for reporting this bug. You can avoid this issue without </pre> Sebastian Marsching 2013-05-20T16:39:42 http://permalink.gmane.org/gmane.comp.php.suphp.general/1148 <pre>Hello did you find a solution for web cgi shell (web.root) then please tell me. I have the same problem on my server._______________________________________________ suPHP mailing list suPHP-qhrM8SXbD5JCREYaNQg7v0EOCMrvLtNR&lt; at &gt;public.gmane.org https://lists.marsching.com/mailman/listinfo/suphp </pre> Dratorus 2013-04-22T19:49:14 http://permalink.gmane.org/gmane.comp.php.suphp.general/1147 <pre>Hi Folks I like to contribute some code to the Joomla-CMS Core. I wrote a little app that searches for updates and mail to the website owner, if any is available. So far not bad. Developed on localhost (xampp/windows), testet on a hosting server (linux/shared). And the script does not work on the hosting-server, because in a parent's class constructor (JApplicationCli = designed for commandline) is a statment, to ensure, that the call is coming from the command-line: if(!defined('STDOUT') | ! defined(STDIN) | !isset($_SERVER['argv'])) { die(); } On the hosting server, that uses suPHP, I figured out that these two constants STDIN and STDOUT are not defined, and thus let the script die. Because the existence of that statement let me assume, that in php-cli-environments generally these two constants should be defined by default. Right? As I am not a server geek, my questions are (and hopefully someone has a answer): - is this statement wrong because these constants must not necessarly are defined</pre> Roger Abt 2013-03-25T18:47:07 http://permalink.gmane.org/gmane.comp.php.suphp.general/1145 <pre>Dear suPHP Users, We are using for years suPHP on our sharehosting servers with success till today. Also we use http://help.directadmin.com/item.php?id=247 for installation. Code: Safe Mode OFF Open BaseDir ON disable_functions:exec,system,passthru,shell_exec,escapeshellarg,escapeshellcmd,proc_close,proc_open,dl,popen,show_sourceexec,system,passthru,shell_exec,escapeshellarg,escapeshellcmd,proc_close,proc_open,dl,popen,show_source /tmp noexec chgrp apache /usr/bin/perl /usr/bin/wget /usr/local/bin/wget /usr/local/bin/curl /usr/bin/curl /usr/bin/python chmod 705 /usr/bin/perl /usr/bin/wget /usr/local/bin/wget /usr/local/bin/curl /usr/bin/curl /usr/bin/python There scan on old joomla installations like 1.5.x 1.6.x 1.7.x and slipstream an upload file into the folder images/stories/* and replace all the index.* files in the server. Yes i know users need always update there joomla to the last stable version. But my biggest concern now is how there bypass suphp? it works for years great, bud it seems </pre> r r 2013-01-22T15:09:14 http://permalink.gmane.org/gmane.comp.php.suphp.general/1144 <pre>Yes. On 26.12.2012 08:58, michal-7dLArxPmfVo&lt; at &gt;public.gmane.org wrote: </pre> joe-ChzM9U5uBbQ< at >public.gmane.org 2012-12-26T16:55:41 http://permalink.gmane.org/gmane.comp.php.suphp.general/1143 <pre>Does suPHP supports HTTP Authentication Header? </pre> michal-7dLArxPmfVo< at >public.gmane.org 2012-12-26T13:58:01 http://permalink.gmane.org/gmane.comp.php.suphp.general/1142 <pre>Hi All, While i am trying to compile suphp-0.7.1 with apache-2.4.3 i got following errors.Plz help me by giving your valuable suggestions. [root&lt; at &gt;mr suphp-0.7.1]# ./configure --prefix=/lamp/suphp --with-apxs=/lamp/apache/bin/apxs --with-apache-user=daemon --with-logfile=/var/log/httpd/suphp_log --with-setid-mode=paranoid --sysconfdir=/etc --with-apr=/lamp/apache/bin/apr-1-config --with-php=/lamp/php/bin/php-cgi --enable-suphp_USE_USERGROUP=yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether build environment is sane... yes checking for a BSD-compatible install... /usr/bin/install -c checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix</pre> jaseemkvt 2012-10-09T03:38:50 http://permalink.gmane.org/gmane.comp.php.suphp.general/1141 <pre>Hi Daniel, On Sun, Sep 23, 2012 at 01:18:57PM -0400, Daniel Ahern wrote: Maybe you missed the following options in suphp.conf: ; Security options allow_file_group_writeable=false allow_file_others_writeable=false allow_directory_group_writeable=false allow_directory_others_writeable=false Sylvain _______________________________________________ suPHP mailing list suPHP-qhrM8SXbD5JCREYaNQg7v0EOCMrvLtNR&lt; at &gt;public.gmane.org https://lists.marsching.com/mailman/listinfo/suphp </pre> Sylvain Rochet 2012-09-23T22:31:02 http://permalink.gmane.org/gmane.comp.php.suphp.general/1140 <pre>Hi, I've got a little problem. We're using a linux webserver with SuPHP, and I need multi-user support so that several programmers may have access to different files. My intention was to use ACLs, but setfacl for user:programmer2:6 sets the mask to 6 (this is necessary, because the mask sets the highest level of permissions for users defined by ACLs) which also causes the group permission to be set to 6. Of course, a file with 660 permissions will not be executed by SuPHP. Is there any way around this or is it simply that SuPHP cannot be used if you need a system where multiple users are able to modify a php file? Thanks, Daniel </pre> Daniel Ahern 2012-09-23T17:18:57 http://permalink.gmane.org/gmane.comp.php.suphp.general/1139 <pre>Hi, On Sun, Aug 19, 2012 at 06:43:12PM +0200, Sylvain Rochet wrote: Well, the previous patch was obviously bogus. This new patch is following Apache advices about brigades[1] and memory usage, it seems like suPHP is using the bad example in suphp_discard_output(). Sylvain [1] http://httpd.apache.org/docs/trunk/developer/output-filters.html#filtering _______________________________________________ suPHP mailing list suPHP-qhrM8SXbD5JCREYaNQg7v0EOCMrvLtNR&lt; at &gt;public.gmane.org https://lists.marsching.com/mailman/listinfo/suphp </pre> Sylvain Rochet 2012-09-06T21:57:54 http://permalink.gmane.org/gmane.comp.php.suphp.general/1138 <pre>Hi, Well, as usual, I couldn't resist about going deeper into the issue. The issue is about suphp_discard_output() which calls apr_bucket_read() (= suphp_bucket_read() ) without freeing the data. So suphp_read_fd() is allocating more and more memory through apr_bucket_alloc(). suphp_read_fd() does not check if apr_bucket_alloc() failed to allocate memory (oh!) and then call apr_bucket_free() with a NULL pointer, which segfaults. Here is a patch for this bug, however I am not an Apache/suPHP internals guru and therefore I don't know if this is the correct way to fix this bug or if this patch fixes all possible memory leaks in this case. Regards, Sylvain _______________________________________________ suPHP mailing list suPHP-qhrM8SXbD5JCREYaNQg7v0EOCMrvLtNR&lt; at &gt;public.gmane.org https://lists.marsching.com/mailman/listinfo/suphp </pre> Sylvain Rochet 2012-08-19T16:43:12 http://permalink.gmane.org/gmane.comp.php.suphp.general/1137 <pre>Hi, One of my hosted managed to crash apache childs with a script running through suPHP. Note the script is not meant to be executed as CGI, this is a regular script inside an abandoned directory index which is running by mistake by web crawlers because the httpd runs .sh scripts as CGI by default. This is fully reproductible and I can give the script which makes it crash to anyone wanting to look deeper into this issue, there is nothing important in this script but I am not sure if disclosing the script here now is a very good idea. The latest apache2 error log line is: [Sun Aug 19 15:05:18 2012] [error] [client 127.0.0.1] malformed header from script. Bad header=#: hidden-script-name.sh Which makes sense, because this is not a CGI script, note the script is still running perfectly after apache child crashed. It looks like suPHP is trying to free() an uninitialised pointer, here is the tracedump: (gdb) run -f /usr/local/apache2/conf/httpd.conf -X Starting program: /usr/local/apache2/bin/ht</pre> Sylvain Rochet 2012-08-19T15:24:47 http://permalink.gmane.org/gmane.comp.php.suphp.general/1136 <pre>You currently have mod_php and suPHP enabled in apache. Either delete or move out of the way conf.d/php.conf as that is what is including mod_php You can see it for yourself in the phpinfo() snippet you pasted: "Server API Apache 2.0 Handler " Also you may need to change "AddType application/x-httpd-php .php" to "AddType x-httpd-php .php" in your httpd.conf so it matches what suphp is supposed to look for. On 7/10/2012 1:59 PM, Shane Graham wrote: </pre> Joe Gillotti 2012-07-11T06:53:00 http://permalink.gmane.org/gmane.comp.php.suphp.general/1135 <pre>Hello, I've been trying to get suPHP working on all my servers but I am having trouble. Every time I comment out the php_module I get about 20 errors and i have run out of options as I am running php as apache and I really do not want to do that. attached are my config files. I removed some information like the sites on it and the directories and paths to the ssl certificates. Some information on the server PHP Version 5.3.3 System Linux i-585-2924-VM 2.6.32-220.13.1.el6.x86_64 #1 SMP Tue Apr 17 23:56:34 BST 2012 x86_64 Build Date May 7 2012 20:14:24 Configure Command './configure' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--c</pre> Shane Graham 2012-07-10T17:59:12 http://permalink.gmane.org/gmane.comp.php.suphp.general/1134 <pre> Generally, when WP calls a bad function it logs to the error log, which in this case it did not. And I was testing it from the command line with /usr/local/bin/php-cgi, which worked, although the previous comment about not duplicating the calling environment exactly does apply. -Dan </pre> Dan Mahoney, System Admin 2012-06-24T23:34:23 http://permalink.gmane.org/gmane.comp.php.suphp.general/1133 <pre>In the wordpress community this problem is known as a WSOD or White Screen Of Death. In my experience it is usually caused by wordpress requesting a function which hasn't been installed or enabled, such as if you haven't got the mysql module (php5-mysql in debian). Different wordpress plugins also come with their own requirements and will also cause this WSOD failure when the relevant modules aren't available. Remember that in at least debian-based systems there are different php.ini locations for cli, cgi, fpm and apache2 SAPIs, so having a successful execution in php-cli may not be indicative that it will work correctly when running through php-cgi (the sapi that suphp interfaces). </pre> Daniel Llewellyn 2012-06-24T22:29:48 http://permalink.gmane.org/gmane.comp.php.suphp.general/1132 <pre> Yeah -- adding a minor check that says "or root" might be helpful there (or having suPHP be able to check for multiple webserver UIDs, for those of us that run webservices under several main uids), but your instructions below are useful. Right. Such a wrapper would need to handle passing the stdin/stdout streams, as well as duplicating the environment vars of the parent. Seems fairly simple. Thanks. This had occured to me, but I hadn't considered the whole setuid issue, so my initial approach seemed like less work. -Dan </pre> Dan Mahoney, System Admin 2012-06-24T20:58:42 http://permalink.gmane.org/gmane.comp.php.suphp.general/1131 <pre>Am 24.06.2012 10:12, schrieb Dan Mahoney, System Admin: The calling syntax is not a secret (after all the source code is open), however I think that this might not be very helpful. As suPHP has the setuid bit set, the kernel should not allow debugging (or rather ignore the setuid bit, if a debugger is attached). However, as suPHP checks for the calling user to be the webserver, calling it as root does not help either. In general, the best way to do debugging (e.g. using strace), is to create a small wrapper shell-script calling PHP with a debugger attached and writing the results to a file. You can then configure suPHP to call this wrapper instead of PHP directly. If you want, you can even limit this to a different handler, thus enabling debugging for certain scripts only. _______________________________________________ suPHP mailing list suPHP-qhrM8SXbD5JCREYaNQg7v0EOCMrvLtNR&lt; at &gt;public.gmane.org https://lists.marsching.com/mailman/listinfo/suphp </pre> Sebastian Marsching 2012-06-24T09:30:11 http://permalink.gmane.org/gmane.comp.php.suphp.general/1130 <pre> Not trust. Truss. FreeBSD's equivalent of strace. I.e. figure out which files are being opened/stat'd, which filehandles are being touched, where session files are failing to be written, etc etc. (Because PHP has crap-all for debugging support). In order to be able to do that, I need to be able to call the "suphp" binary just as mod_suphp would, and supply the same environment the webserver would. Entirely likely, and it worked, but I'm looking for the system-level diagnostic, rather than the application-level fix, if that makes sense. Ah well. -Dan </pre> Dan Mahoney, System Admin 2012-06-24T09:15:17 http://permalink.gmane.org/gmane.comp.php.suphp.general/1129 <pre> 1) With suPHP, it generally isn't possible for a malicious script to harm anything aside from what the user who's running the script can access. You shouldn't need to worry about trusting it at that point. 2) WordPress is quirky. Maybe it's an issue with a custom theme, or how it detects how to encode the content to the web browser based on the Accept or UserAgent headers which are nonexistent when ran from the command line. Most likely if you try out a broken-ish WordPress install with mod_php rather than suPHP it will act the same way. On 6/24/2012 4:48 AM, Dan Mahoney, System Admin wrote: </pre> Joe Gillotti 2012-06-24T08:58:33 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.php.suphp.general