Fedora has issued an advisory today (September 7): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/G3GS7G4X3FRAUBMBVQ4QXZAGZH2JIMG4/ More details in the RedHat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1623265 Mageia 5 and Mageia 6 are also affected.
Assigning to the registered maintainer.
CC: (none) => marja11Assignee: bugsquad => shlomif
apache-mod_perl-2.0.10-5.mga7 submitted for cauldron
CC: (none) => brunoStatus: NEW => ASSIGNEDVersion: Cauldron => 6Assignee: shlomif => bruno
apache-mod_perl-2.0.10-1.1.mga6 submitted for mga6
Assignee: bruno => qa-bugs
It didn't build.
Assignee: qa-bugs => bruno
apache-mod_perl-2.0.10-6.mga7 and apache-mod_perl-2.0.10-1.1.mga6 have been uploaded
Advisory: ======================== Updated apache-mod_perl packages fix security vulnerability: A flaw was found in mod_perl 2.0 through 2.0.10 which allows attackers to execute arbitrary Perl code by placing it in a user-owned .htaccess file, because (contrary to the documentation) there is no configuration option that permits Perl code for the administrator's control of HTTP request processing without also permitting unprivileged users to run Perl code in the context of the user account that runs Apache HTTP Server processes (CVE-2011-2767). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2767 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/G3GS7G4X3FRAUBMBVQ4QXZAGZH2JIMG4/ ======================== Updated packages in core/updates_testing: ======================== apache-mod_perl-2.0.10-1.1.mga6 apache-mod_perl-devel-2.0.10-1.1.mga6
MGA6-32 MATE on IBM Thinkpad R50e No installation issues Used # urpmq --whatrequires apache-mod_perl but nothing came out that I could put my teeth in. Is clean install OK???
CC: (none) => herman.viaene
Also use httpd -M to make sure it loaded the module OK and that Apache runs with it without crashing.
httpd -M shows amongst others: perl_module (shared) Sufficient for OK'ing????
If that's all you can do. Would be nice to test that it doesn't crash if possible.
I used apache in bug 23826 with this update, and another one Which is gone from the update list now.
It feels like I'm treading in unknown waters here, crocodiles nipping at my heels, but plunging ahead anyway. I know nothing here, but just going by package names, it would appear that this bug and Bug 22833 are related, if perhaps distantly. Should they be tested together, and perhaps pushed together? Or should one or the other be done first? Realizing, of course, that this one is labeled as critical, where Bug 22833 is not. (Posting a similar comment in bug 22833.)
CC: (none) => andrewsfarm
Trying M6/64 BEFORE update @David, possibly Herman The best clue is from Herman: https://bugs.mageia.org/show_bug.cgi?id=16505#c22 which indicates a script at: https://perl.apache.org/docs/2.0/user/intro/start_fast.html which I have copied and named 'rock.pl' and put into '/var/www/cgi-bin' [rather than ../html] which already had a couple of things; and made executable. What User & group: apache? [I will attach it later]. #ls -l /var/www/cgi-bin/ -rwxr-xr-x 1 lewis lewis 340 Tach 27 21:06 rock.pl* I did not understand from Herman's earlier success: > Only changed location of the test file rock.pl to /var/www/html and > consequently the first line of the added item in the httpd.conf file to: > Alias /perl/ /var/www/html/ which relates I think to: ----- Now we can configure our module in httpd.conf: <Location /rocks> SetHandler perl-script PerlResponseHandler MyApache2::Rocks </Location> ---- After installing apache-mod_perl and re-starting httpd: # httpd -M includes 'perl_module (shared)' Going to http://localhost/rocks gives "Object not found! Error 404 localhost Apache/2.4.37 (Mageia) PHP/5.6.38 mod_perl/2.0.10 Perl/v5.22.3" which is reasonable in the circumstances. So please some advice on what to put in /etc/httpd/conf/httpd.conf to get this simple test to work. TIA
CC: (none) => lewyssmith
If you put a perl script in cgi-bin, Apache will execute perl directly; it will *not* use mod_perl. Unless something is wrong with the package, it should work in /var/www/html without any additional configuration, but I've never used it before.
@Lewis (welcome back!) The change in location I refer to, is that in the original site (the mod_perl page) the rock.pl was located in a /home folder, so the alias in httpd.conf for perl has to point to the location of the .pl file. I guess you didn't do that, tried another approach???
You only need to configure aliases when you put things outside of /var/www/html. If you want to serve files from within your home directory, install apache-mod_userdir and put the files in ~/public_html and then they'll be accessible under http://localhost/~username
Got nowhere. Asking Shlomi.
No reply to date. Explored /etc/httpd/ re perl, and in /etc/httpd/conf/conf.d/perl.conf UNcommented the following Alias section which looks relevant: # Mod_perl incorporates a Perl interpreter into the Apache web server, # so that the Apache web server can directly execute Perl code. # Mod_perl links the Perl runtime library into the Apache web server Alias /perl /var/www/perl <Directory /var/www/perl> SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI </Directory> Re the section above, I put rock.pm in /var/www/perl/ after making the 'perl' subdirectory. Re-started Apache: # systemctl restart httpd http://localhost/perl/rock.pm then gave a blank screen, better than before. To persue.
Regarding CVE-2011-2767 there is supposed to be a way to reproduce the bug. And there is also a note somewhere from RedHat saying "won't fix". Shall try to get a grasp of the setup and try the PoC, later.
CC: (none) => tarazed25
Lewis, mod_perl uses .pl, I think, unless you've set AddHandler to include .pm. Cheers, Stig
CC: (none) => smelror
(In reply to Len Lawrence from comment #19) > Regarding CVE-2011-2767 there is supposed to be a way to reproduce the bug. This is all I saw: "To reproduce the bug, add "PerlOptions -Sections"' to the global configuration or to any <VirtualHost> container." I doubted whether this would get us anywhere. > Shall try to get a grasp of the setup and try the PoC, later. If you can get apache-mod_perl to work anyhow, that should do us: that it behaves the same before & after the update. We need to be sure that the test script goes via mod_perl rather than being executed independently. FWIW Following links about this, I found: https://mediatemple.net/community/products/dv/204643090/running-scripts-outside-of-the-cgi-bin "You can enable server-wide processing of cgi scripts. Note that this will make your server more vulnerable if you get hacked. To do this, uncomment the cgi-script AddHandler directive in the main Apache configuration file, /etc/httpd/conf/httpd.conf." In that file, I UNcommented & appended to: AddHandler cgi-script .cgi .pl .pm and re-started Apache. Same behaviour as before: http://localhost/perl/rock.pm gave a blank screen; http://localhost/perl/rock.pl asked to open (edit) or save the script. Lost...
Thanks Lewis - will digest that at my leisure (!). This is what I have tried so far. Before update: # httpd -M [...] perl_module (shared) php_module (shared) $ systemctl status httpd ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset Active: active (running) since Fri 2018-11-30 18:59:04 GMT; 8min ago The post at https://mail-archives.apache.org/mod_mbox/perl-modperl/201110.mbox/raw/%3C20111004084343.GA21290%40ktnx.net%3E talks about reproducing the bug (not sure which bug but the CVE link led here) by placing 'PerlOption: Sections' in /etc/apache2/conf.d/all_vhosts and running # apache2ctl configtest Tried # apachectl configtest AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.1.103. Set the 'ServerName' directive globally to suppress this message Syntax OK Ignored the apache2 stuff and tried the main config file httpd.conf. Added 'PerlOption -Sections' after ServerAdmin. Could not restart httpd.service... # systemctl restart httpd.service Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details. # systemctl status httpd.service ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset Active: failed (Result: exit-code) since Fri 2018-11-30 19:30:12 GMT; 59s ago Process: 13325 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, s Main PID: 13325 (code=exited, status=1/FAILURE) Status: "Reading configuration..." So it did not like that option or maybe where it was placed. # apachectl configtest AH00526: Syntax error on line 86 of /etc/httpd/conf/httpd.conf: Invalid command 'PerlOption', perhaps misspelled or defined by a module not included in the server configuration I have to give up - completely out of my depth here. Reverted and installed apache-mod_userdir and created directory ~/public_html. Copied rocks.pl there. In firefox tried localhost/<user>/ expecting to see the file listed but got error 404, and the same when the filename was added. Tried copying the file to /var/www/html and pointing the browser to localhost/rocks.pl That returned error 404 again. Might have misunderstood David's remarks. Maybe the configuration step is necessary after all.
Something weird here. localhost directs me to the nginx welcome page and talks about editing the nginx.conf file. It should say "It works!". nginx is not even installed and there is nothing in /etc concerning nginx. It has been tested in the past but is no longer present. Shall login on another partition to see if the same thing happens.
No trouble on another machine but on this one it persists even in mga7 so it is a problem in userland. No references to nginx anywhere on the whole system. Either the system is insane or the user is.
You should not be using AddHandler, we want mod_perl not CGI. Nginx should be disabled and Apache should be started. If using public_html, the URL should have a tilde before the username.
I did say that Apache was running and that Nginx is completely disabled, absent, dead. It is nowhere on the system! How the hell do I get rid of it? What is AddHandler - never heard of it?
Tried localhost/~/rocks.pl Same thing: error 404. The nginx thing is a mystery. Used locate and grep all over my .config and .local directories and could see nothing relevant. The fact that it is happening with localhost/ implies some misconfiguration which could well nullify anything sent to it.
(In reply to Len Lawrence from comment #26) > I did say that Apache was running and that Nginx is completely disabled, > absent, dead. It is nowhere on the system! How the hell do I get rid of it? Comments 22 and 23 suggest otherwise. You won't get 404's for things Apache is looking for, nor get an nginx welcome page, if Apache is running. Run (as root): netstat -ntlp | grep 80, to see which process is running on that port. > What is AddHandler - never heard of it? Lewis brought it up in Comment 21.
(In reply to Len Lawrence from comment #27) > Tried localhost/~/rocks.pl > Same thing: error 404. I would have been more explicit if my cell phone had a tilde. http://localhost/~username/rocks.pl corresponds to /home/username/public_html/rocks.pl
Thanks David. I always thought ~ and <username> were equivalent but this has to be seen from the point of view of the webserver where they are obviously not equivalent.
Yep, basically Apache looks for three things. If the URL starts with ~<something>/ then it engages mod_userdir and looks in /home/<something>/public_html If the URL starts with something that matches an Alias in the Apache configuration, it looks in the directory that the configured Alias refers to Otherwise it looks under /var/www/html/
Moved to yet another machine and installed the core version of apache-mod_perl. Set up user directory public_html and copied rocks.pl there. Restarted httpd.service. http:/localhost/~lcl/rocks.pl Error 404 $ sudo cp rocks.pl /var/www/html/ http:/localhost/rocks.pl Error 404 and "What should Firefox do with this file?" At least the server is looking in /var/www/html but it does not know what to do with it, which means that mod_perl is not operating. Ah, now I see that David was talking to you Lewis. Trying the reconfiguration stuff from comment 18 next.
If you're still getting bogus 404's, looks at the logs in /var/www/html and see what the problem is. You will need "other" execute permissions on your home directory and public_html if you want to use mod_userdir.
Aargh! Forgot to install apache-mod_userdir on this new machine. http:/localhost/~lcl/rocks.pl Error 403 - Access forbidden! You don't have permission to access the requested object. It is either read-protected or not readable by the server. $ ll rocks* -rwxr-xr-x 1 lcl lcl 86 Nov 30 19:48 rocks.pl* This again seems to imply that mod_perl is not being used. Thanks for the 'other' suggestion. Trying that just now.
No progress yet. Poked around in /var/log/httpd/ but all that could be seen were the GET commands and the subsequent 403 errors. Leaving this until tomorrow - shall investicate httpd.conf and perl.conf if it exists.
(In reply to Len Lawrence from comment #35) > No progress yet. Poked around in /var/log/httpd/ but all that could be > seen were the GET commands and the subsequent 403 errors. In access_log, but what about error_log?
(In reply to Len Lawrence from comment #34) > Aargh! Forgot to install apache-mod_userdir on this new machine. > > http:/localhost/~lcl/rocks.pl > Error 403 - Access forbidden! > You don't have permission to access the requested object. It is either > read-protected or not readable by the server. > $ ll rocks* > -rwxr-xr-x 1 lcl lcl 86 Nov 30 19:48 rocks.pl* > > This again seems to imply that mod_perl is not being used. > > Thanks for the 'other' suggestion. Trying that just now. your /home/lcl has permission 0700, but for apache to access public_html, you need 0711
CC: (none) => tmb
Back on the old machine. Fixed /home/lcl. Thanks Thomas. Still error 403. Fixed /home/lcl on the new machine and again error 403. Back to checking configurations - but later.
Still cannot figure out where nginx is coming from on this one machine. $ systemctl status httpd.service ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset Active: active (running) since Fri 2018-11-30 20:34:22 GMT; 2h 41min ago No sign of anything nginx in system directories and the fact that it travels from partition to partition implies that the trouble must lie on the fixed home partition because that is the one constant. It even shows up on a newly installed cauldron, which has seen no signs of nginx testing. Definitely something to do with /home/... Some script maybe that the user does not know about but valid at localhost.
@David, comment 36. Yes, there are references to mod_perl and the message "Could not reliably determine the server's fully qualified domain name, using 192.168.1.103. Set the 'ServerName' directive globally to suppress this message I guess that means in httpd.conf. Shall try that later. Found an nginx directory in /var/log with recent error and access logs. locate seems to have missed that. Removing nginx directories as they appear. localhost still presents nginx welcome. Baffled.
Did you check netstat (Comment 28)? Did you check /var/www/html/ for left behind files from previous tests (especially index.html)?
/var/www/html/index.html was checked already - source of "It works!" message. Sorry; somehow missed seeing the netstat recommendation. Had been wondering how to check port 80. $ sudo netstat -ntlp | grep 80 [...] tcp6 0 0 :::80 :::* LISTEN 13413/httpd
There is a lot of data at /proc/13413/. status contains references to apache and postfix.
Finally. Added this stanza to /etc/httpd/conf.d/perl.conf, based on comment 18: Alias /perl /var/www/html <Directory /var/www/html> SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI </Directory> Restarted apache and http://localhost/rocks.pl which yielded "mod_perl 2.0 rocks!" Updated the packages and restarted apache. The localhost test returns the same result, which may be enough to pass this update. The local user test failed without any error. Presumably that would need another entry in perl.conf but I would not know how to define the Alias. An either/or situation maybe?
@Len: Phew - all that work; but not for nothing! Pick your medal. I reviewed & revised the changes I had done in comments 18 & 21. I never had Len's complications of http://localhost/ "It works!" not working; nor nginx. * /etc/httpd/conf/conf.d/perl.conf Revised the directory /var/www/perl to /var/www/html in the stanza cited above c44. * Moved the script copies rock.pl & rock.pm to /var/www/html . * /etc/httpd/conf/httpd:.conf Following David's advice in c25: > You should not be using AddHandler I RE-commented the line: # AddHandler cgi-script .cgi Re-started httpd. Then I was back to before: http://localhost/rock.pl wanted to save the file; http://localhost/rock.pm showed a blank page. I noticed a slight path difference between Len & myself: /etc/httpd/conf/conf.d/perl.conf /etc/httpd/conf.d/perl.conf so created *his* path (the second) and copied the perl.conf file to that. Same result. ------------ FWIW I updated to: apache-mod_perl-2.0.10-1.1.mga6 re-started Apache, got the same result - as in c18! --------------------------------------------------- Putting the 64-bit OK for Len, validating, doing the advisory from comment 6.
Keywords: (none) => advisory, validated_updateWhiteboard: (none) => MGA6-64-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0474.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED