Bug 159289

Summary: mod_auth_ldap causes httpd child segfault when used with other mod_auth_*
Product: Red Hat Enterprise Linux 4 Reporter: Jared Jennings <jared.jennings>
Component: httpdAssignee: Joe Orton <jorton>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2005-622 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-05 15:38:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 156322    

Description Jared Jennings 2005-06-01 13:59:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Description of problem:
I set Apache up to use mod_auth_ldap to authenticate against an Active Directory server, and mod_auth_pgsql to authenticate against a local user/group database. Each module functioned correctly when used exclusively. But when both were enabled, and I authenticated against mod_auth_pgsql successfully, mod_auth_ldap caused the httpd child process to segfault.

Use of gdb revealed that mod_auth_ldap was attempting, in the mod_auth_ldap_auth_checker function (httpd-2.0.52/modules/experimental/mod_auth_ldap.c:405) to consult a mod_auth_ldap_request_t *req (assigned at line 408) which is normally put in place by mod_auth_ldap_check_user_id. 

But in the case where mod_auth_pgsql was the module which successfully authenticated me, that structure was not created by mod_auth_ldap_check_user_id, and the req pointer in mod_auth_ldap_auth_checker was NULL.

Attached is a patch which causes mod_auth_ldap to decline authorization if the authentication structure is unassigned (req is NULL). The behavioral impact of this patch should be small, because if a user is not in the LDAP directory, the odds are that that user cannot be in a group in the LDAP directory. This is certainly true for Active Directory.

The security impact of this bug is low but non-negligible: it does not result in unauthorized access, but could be used to mount a DoS attack against the web server.

Version-Release number of selected component (if applicable):
httpd-2.0.52-9.ent

How reproducible:
Always

Steps to Reproduce:
1. Configure Apache to authenticate using mod_auth_pgsql (loaded first, non-authoritative) and mod_auth_ldap (loaded after mod_auth_pgsql, authoritative or non-authoritative). Point mod_auth_ldap at an AD server and mod_auth_pgsql at a database.
2. Configure Apache to limit access to a directory using Require group and an AD group (Require group CN=foo,OU=bar,OU=baz,DC=bletch,DC=com).
3. Use a web browser to access a page in the access-limited directory. Authenticate using the user added to the database, not a valid AD user.
  

Actual Results:  Client side:
(Firefox) The contents of the browser's content pane does not change.
(IE) An error page is displayed.

Server side:
A message is produced in the error_log about an httpd child process receiving a SIGSEGV.

Expected Results:  Client side:
The browser displays the page.

Server side:
Nothing is produced in the error_log.

Additional info:

The patch:

diff -ruN httpd-2.0.52/modules/experimental/mod_auth_ldap.c httpd-2.0.52-patch/modules/experimental/mod_auth_ldap.c
--- httpd-2.0.52/modules/experimental/mod_auth_ldap.c   2004-05-21 18:39:41.000000000 -0500
+++ httpd-2.0.52-patch/modules/experimental/mod_auth_ldap.c     2005-05-12 10:22:14.144815969 -0500
@@ -431,6 +431,15 @@
         return DECLINED;
     }

+       if (!req) {
+               /* Some other module did the check_user_id step and now we're getting
+                * called on the auth_checker step. req contains nothing and if we
+                * try to access it we'll segfault. Run away! Run away!
+                * [Jared L. Jennings, 12 May 2005]
+                */
+               return DECLINED;
+       }
+
     if (sec->host) {
         ldc = util_ldap_connection_find(r, sec->host, sec->port,
                                        sec->binddn, sec->bindpw, sec->deref,

Comment 1 Joe Orton 2005-06-02 15:47:45 UTC
Thanks at lot for the report and patch.

This looks sensible; it should probably be changed to return HTTP_FORBIDDEN
instead of DECLINE-ing if mod_auth_ldap is configured to be authoritative for
the request context, however.

Comment 2 Jared Jennings 2005-06-09 14:57:47 UTC
diff -ru httpd-2.0.52-rh/modules/experimental/mod_auth_ldap.c httpd-
2.0.52/modules/experimental/mod_auth_ldap.c
--- httpd-2.0.52-rh/modules/experimental/mod_auth_ldap.c	2004-05-21 
18:39:41.000000000 -0500
+++ httpd-2.0.52/modules/experimental/mod_auth_ldap.c	2005-06-09 
09:34:43.821911226 -0500
@@ -431,6 +431,15 @@
         return DECLINED;
     }
 
+	if (!req) {
+		/* Some other module did the check_user_id step and now we're 
getting 
+		 * called on the auth_checker step. req contains nothing and if 
we 
+		 * try to access it we'll segfault. Run away! Run away!
+		 * [Jared L. Jennings, 12 May 2005]
+		 */
+		return sec->auth_authoritative? HTTP_UNAUTHORIZED : DECLINED;
+	}
+
     if (sec->host) {
         ldc = util_ldap_connection_find(r, sec->host, sec->port,
                                        sec->binddn, sec->bindpw, sec->deref,



Comment 6 Joe Orton 2005-08-01 19:30:13 UTC
Thanks again for the patch.

Experimental test update packages, including this patch and a number of other
stability fixes for mod_ldap/mod_auth_ldap, are available here:

  http://people.redhat.com/jorton/Nahant-httpd/

Comment 7 Red Hat Bugzilla 2005-10-05 15:38:14 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-622.html