Bug 23541 - apache-mod_perl new security issue CVE-2011-2767
Summary: apache-mod_perl new security issue CVE-2011-2767
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal critical
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA6-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2018-09-07 19:40 CEST by David Walser
Modified: 2018-12-02 23:16 CET (History)
9 users (show)

See Also:
Source RPM: apache-mod_perl-2.0.10-3.mga7.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2018-09-07 19:40:01 CEST
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.
Comment 1 Marja Van Waes 2018-09-08 13:28:10 CEST
Assigning to the registered maintainer.

Assignee: bugsquad => shlomif
CC: (none) => marja11

Comment 2 Bruno Cornec 2018-10-22 22:49:43 CEST
apache-mod_perl-2.0.10-5.mga7 submitted for cauldron

CC: (none) => bruno
Assignee: shlomif => bruno
Status: NEW => ASSIGNED
Version: Cauldron => 6

Comment 3 Bruno Cornec 2018-10-23 11:43:29 CEST
apache-mod_perl-2.0.10-1.1.mga6 submitted for mga6

Assignee: bruno => qa-bugs

Comment 4 David Walser 2018-10-23 14:18:48 CEST
It didn't build.

Assignee: qa-bugs => bruno

Comment 5 Bruno Cornec 2018-10-24 21:00:50 CEST
apache-mod_perl-2.0.10-6.mga7 and apache-mod_perl-2.0.10-1.1.mga6 have been uploaded

Assignee: bruno => qa-bugs

Comment 6 David Walser 2018-10-25 00:43:33 CEST
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
Comment 7 Herman Viaene 2018-11-15 12:19:07 CET
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

Comment 8 David Walser 2018-11-15 14:40:20 CET
Also use httpd -M to make sure it loaded the module OK and that Apache runs with it without crashing.
Comment 9 Herman Viaene 2018-11-16 14:52:08 CET
httpd -M shows amongst others:
 perl_module (shared)
Sufficient for OK'ing????
Comment 10 David Walser 2018-11-16 16:08:07 CET
If that's all you can do.  Would be nice to test that it doesn't crash if possible.
Comment 11 Herman Viaene 2018-11-17 12:18:03 CET
I used apache in bug 23826 with this update, and another one Which is gone from the update list now.
Comment 12 Thomas Andrews 2018-11-19 15:48:06 CET
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

Comment 13 Lewis Smith 2018-11-27 21:42:31 CET
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

Comment 14 David Walser 2018-11-28 01:52:35 CET
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.
Comment 15 Herman Viaene 2018-11-28 10:53:42 CET
@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???
Comment 16 David Walser 2018-11-28 13:49:13 CET
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
Comment 17 Lewis Smith 2018-11-28 21:51:54 CET
Got nowhere. Asking Shlomi.
Comment 18 Lewis Smith 2018-11-29 21:55:28 CET
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.
Comment 19 Len Lawrence 2018-11-30 09:12:33 CET
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

Comment 20 Stig-Ørjan Smelror 2018-11-30 17:58:58 CET
Lewis,

mod_perl uses .pl, I think, unless you've set AddHandler to include .pm.

Cheers,
Stig

CC: (none) => smelror

Comment 21 Lewis Smith 2018-11-30 20:23:31 CET
(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...
Comment 22 Len Lawrence 2018-11-30 21:06:24 CET
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.
Comment 23 Len Lawrence 2018-11-30 21:19:39 CET
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.
Comment 24 Len Lawrence 2018-11-30 21:41:41 CET
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.
Comment 25 David Walser 2018-11-30 21:47:56 CET
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.
Comment 26 Len Lawrence 2018-11-30 22:16:17 CET
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?
Comment 27 Len Lawrence 2018-11-30 22:32:46 CET
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.
Comment 28 David Walser 2018-11-30 22:55:21 CET
(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.
Comment 29 David Walser 2018-11-30 22:56:22 CET
(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
Comment 30 Len Lawrence 2018-11-30 23:06:56 CET
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.
Comment 31 David Walser 2018-11-30 23:09:46 CET
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/
Comment 32 Len Lawrence 2018-11-30 23:16:48 CET
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.
Comment 33 David Walser 2018-11-30 23:21:45 CET
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.
Comment 34 Len Lawrence 2018-11-30 23:25:04 CET
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.
Comment 35 Len Lawrence 2018-11-30 23:41:00 CET
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.
Comment 36 David Walser 2018-11-30 23:42:16 CET
(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?
Comment 37 Thomas Backlund 2018-11-30 23:48:13 CET
(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

Comment 38 Len Lawrence 2018-12-01 00:25:42 CET
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.
Comment 39 Len Lawrence 2018-12-01 00:57:45 CET
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.
Comment 40 Len Lawrence 2018-12-01 01:41:25 CET
@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.
Comment 41 David Walser 2018-12-01 02:10:58 CET
Did you check netstat (Comment 28)?  Did you check /var/www/html/ for left behind files from previous tests (especially index.html)?
Comment 42 Len Lawrence 2018-12-01 09:59:56 CET
/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
Comment 43 Len Lawrence 2018-12-01 10:08:48 CET
There is a lot of data at /proc/13413/.  status contains references to apache and postfix.
Comment 44 Len Lawrence 2018-12-01 11:47:06 CET
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?
Comment 45 Lewis Smith 2018-12-02 15:55:53 CET
@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.

Whiteboard: (none) => MGA6-64-OK
Keywords: (none) => advisory, validated_update
CC: (none) => sysadmin-bugs

Comment 46 Mageia Robot 2018-12-02 23:16:23 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0474.html

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.