Apache 2.4 config too permissive / PerlAuthenHandler integration problem

Bug #1449283 reported by Bill Erickson on 2015-04-27
260
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Critical
Unassigned
2.6
Critical
Unassigned
2.7
Critical
Unassigned

Bug Description

Ubuntu 14.04
Apache 2.4
Evergreen master.

Stock Evergreen install w/ Apache 2.4 is not enforcing authentication when using OpenILS::WWW::Proxy::Authen + "require all granted". For example, load the following file in the browser and it will not require credentials, though it is configured to:

https://DOMAIN/opac/extras/circ/alt_holds_print.js

I traced this to the presence of "require all granted" in the <Location /opac/extras/circ> block (and similar blocks). When present, Apache never calls the handler for OpenILS::WWW::Proxy::Authen. It just lets everyone in.

"require all granted" was added in the early 2.4 days because, IIRC, it was intended as a replacement for "allow from all" -- i.e. don't restrict by IP.

Removing "require all granted" allows the authentication check to proceed within Authen.pm, but Apache eventually produces a 500 error:

AH00027: No authentication done but request not allowed without authentication for /opac/extras/circ/alt_holds_print.js. Authentication not configured?

Can someone please confirm this on another Apache 2.4 server? I hope I'm just missing something...

FWIW, reverting to the old-style OpenILS::WWW::Proxy configuration works as expected.

Dan Scott (denials) wrote :

Sounds bad, and possibly like something dating way back to my early work with Apache 2.4, which makes me feel worse.

What do you mean by "old-style OpenILS::WWW::Proxy configuration"?

Bill Erickson (berick) wrote :

For old-style configs, I basically mean rolling this back:

http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=f9493ae5b5416ff17685b9c8dcc0b813336f0ad8

The old OpenILS::WWW::Proxy handler is not affected by changes in Apache authentication layer.

Thomas Berezansky (tsbere) wrote :

I ran into some of the issues with the Authen handler myself, actually. At the time I couldn't find sufficient documentation on the mod perl changes to attempt to fix it, so I put it on the back burner until they officially released the newer mod perl (they hadn't at the time). I do recall that some of the problems are related to the basic auth prompt and authenticating with a pre-existing cookie.

In the end I ended up figuring out how to make the AccessHandler module as a combination of replacement for some of what I needed the Authen handler for and a more patron-friendly login for new use cases:
https://bugs.launchpad.net/evergreen/+bug/1413624

I have not found time to go back and see if I could fix the Authen handler itself, though.

Bill Erickson (berick) wrote :

Question for Thomas.. If we rolled back the use of ::Authen module for 2.4, at least temporarily, would we lose any documented features for the stock protected paths (/reporter/, /conify/, etc.)?

Thomas Berezansky (tsbere) wrote :

I wrote Authen originally to allow for other Apache features to "fall through" where the non-Authen wouldn't let them. Specifically, initially anyway, directory indexes for staff-accessible files. I don't think any stock behavior relies on that kind of fall through, but I haven't double-checked that something hasn't snuck in when I wasn't paying close attention to things.

Bill Erickson (berick) wrote :

I've pushed a commit which reverts the use of ::Authen to the old ::Proxy module in the sample Apache 2.4 config.

security/user/berick/lp1449283-ap24-old-school-proxy

If possible, I'd like to get this merged before cutting 2.8.1, etc.

In the interest of time, I did not attempt to get the newer AccessHandler code working for each of the protected directories. Once the basic fix is merged, perhaps we can open a new ticket to see about integrating that and/or keeping tabs on the mod_perl / ::Authen problems.

Changed in evergreen:
milestone: none → 2.8.1
tags: added: pullrequest
Jason Stephenson (jstephenson) wrote :

While I think reverting the changes is a decent short term mitigation, it sounds like the long term solution is getting the authentication handler to work properly with 2.4.

Galen Charlton (gmc) wrote :

I have a branch in progress that should fix the handler - I'll push it to the security repo in 10 minutes.

Galen Charlton (gmc) wrote :

I've pushed a patch to user/gmcharlt/lp1449283_fix_authen_handler in the security repo that repairs the Apache config and tweaks ::Authen to set the username in the mod_perl request object upon successful authentication, as that's apparently required to avoid the "No authentication done but request not allowed without authentication" errors.

I lightly tested this patch under Apache 2.4 but not 2.2.

Bill Erickson (berick) wrote :

Thanks, Galen. Testing your branch now.

Galen Charlton (gmc) wrote :

I've verified by inspection of the Apache httpd Git repository and their bug database that staring in 2.4.x, authn handlers are indeed expected to ensure that $r->user is set. This comment sums it up:

https://bz.apache.org/bugzilla/show_bug.cgi?id=42995#c9

Chris Sharp (chrissharp123) wrote :

I just tested this on Ubuntu 14.04/Evergreen 2.8.0/Apache 2.4 and it prompted me for authentication after the fix.

Chris Sharp (chrissharp123) wrote :

Well, specifically, I was able to view report output without authentication before the fix. After the fix, the URL was redirected to HTTPS and I was prompted to log in.

Jason Stephenson (jstephenson) wrote :

I don't know if anyone else has seen this, but it does not appear to prompt me on 2.2 after installing Galen's branch.

Apache 2.4 works as expected with the branch.

Bill Erickson (berick) wrote :

I have not tested 2.2, but can (als) confirm it works as intended in 2.4.

Bill Erickson (berick) wrote :

(also)

Galen Charlton (gmc) wrote :

> I don't know if anyone else has seen this, but it does not appear to prompt me
> on 2.2 after installing Galen's branch.

Is this happening on a clean slate, such as (say) a Chrome incognito window? Chrome, at least, will hang onto HTTP basic auth credentials and resend them.

Jason Stephenson (jstephenson) wrote :

Firefox was hanging on to something. I cleared my active logins and cache and cookies, but was still getting the page.

I had to clear to everything from all of time to get this to work.

Guess it was hanging on to something from my previous session with the VM running 2.4.

I'd say it is still working as intended with 2.2.

Chris Sharp (chrissharp123) wrote :

I can also confirm it's working as expected with report output post-patch on Ubuntu 12.04/Apache 2.2.

Jason Stephenson (jstephenson) wrote :

I pushed a signoff to security/user/dyrcona/lp1449283_fix_authen_handler_signoff.

I'll let Bill or someone else merge it if they like. Might be fun to have everyone signoff on it, just for kicks. :)

tags: added: signedoff
Bill Erickson (berick) wrote :

I've also confirmed the "Require" vs "require" has no effect, so the upgrade notes only have to mention removing the "require all granted" part.

Bill Erickson (berick) wrote :

I'll add a security blurb to the 2.8.1 release notes and push to secure branch so others can port as needed.

Bill Erickson (berick) wrote :

3rd sign-off plus minor typo repair and additional commit for 2.8.1 release notes security blurb pushed:

security/user/berick/lp1449283-authen-so-and-notes

Proofreading appreciated :)

Jason Stephenson (jstephenson) wrote :

Release notes have trailing whitespace in the sample apache configuration blocks, but other than that look really good to me.

Dunno if the whitespace is intentional or even a problem.

Bill Erickson (berick) wrote :

Whitespace is result of copy/paste Apache configs. That won't affect the asciidoc rendering. Thanks, Jason.

Galen Charlton (gmc) wrote :

I've reviewed and signed off on the release notes and pushed to user/gmcharlt/lp1449283-authen-so-and-notes-so in the security repo.

I also removed those pesky trailing spaces. ;)

Bill Erickson (berick) on 2015-05-01
information type: Private Security → Public Security
Galen Charlton (gmc) on 2015-05-15
Changed in evergreen:
importance: Undecided → Critical
status: New → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.