Apache HTTP Server (httpd) is the most popular web server software in the world, powering millions of websites. But even mature projects like Apache httpd sometimes have vulnerabilities that can put your data at risk. One such vulnerability is CVE-2017-3167, which lets attackers sneak past authentication checks under certain conditions.

In this article, we’ll break down what CVE-2017-3167 is, how it happens, how attackers can exploit it, and how you can defend your servers. We'll keep the explanation practical—with real-life code snippets—so you’ll know what to look for and what to fix.

What is CVE-2017-3167?

CVE-2017-3167 affects Apache HTTPd versions 2.2.x before 2.2.33 and 2.4.x before 2.4.26. It's about how third-party Apache modules use the function ap_get_basic_auth_pw() at the wrong time, which can accidentally let unauthorized users bypass authentication.

In short: calling a function out of sequence can make your server think a user is authenticated… when they’re not.

Where's the Bug?

The core problem is that ap_get_basic_auth_pw() (which gets a user’s password from the request) is supposed to be called only during the authentication phase. But some third-party modules have called it later, for example, in the authorization or even logging phase.

If that happens, Apache's internal authentication state isn’t checked right—so a request that should be denied could actually get through.

Here's a simplified example (in C) that simulates what happens in a vulnerable Apache module

#include "httpd.h"
#include "http_protocol.h"
#include "http_request.h"

static int my_module_handler(request_rec *r) {
    const char *user;
    const char *pw;

    // This should ONLY be called in the authentication phase.
    if (ap_get_basic_auth_pw(r, &pw) == OK) {
        user = r->user;
        // Now assume user is authenticated! But maybe they are not!
        if (strcmp(user, "admin") == ) {
            // Do admin stuff
            ap_rputs("Welcome, admin!", r);
            return OK;
        }
    }

    ap_note_basic_auth_failure(r);
    return HTTP_UNAUTHORIZED;
}

If my_module_handler() is called during the wrong phase (for example, Authorization, not Authentication), it can leak access without properly checking credentials!

Attackers can exploit CVE-2017-3167 if

1. There is a third-party module (or a custom one) using ap_get_basic_auth_pw() outside the authentication phase.

The module is used to protect sensitive routes or resources.

If an attacker discovers such a module, they can bypass authentication by making requests to resources that should be protected. No special credentials required.

Exploit Example

Suppose a website has a vulnerable module wanting to restrict /admin to admins only. But the handler checks authentication credentials in the wrong phase:

- Attacker simply requests /admin without any Authorization header.

Exploit with curl might look like

curl http://target-site.com/admin

If the handler is vulnerable, the attacker could get the page’s real content instead of the usual "401 Unauthorized" error.

The Fix

The flaw is fixed in Apache httpd 2.2.33 and 2.4.26. The fix ensures ap_get_basic_auth_pw() returns an error if called outside the authentication phase.

If you build modules: Always check what phase your code runs in before calling authentication helpers! Don’t assume users are authenticated just because you get a username from the request.

Patch Reference

- Official Apache httpd advisory
- Upstream patch diff

Upgrade your Apache HTTP Server to at least 2.2.33 or 2.4.26.

- Audit any third-party or custom modules for use of ap_get_basic_auth_pw(); make sure calls only happen in the Authentication phase.

More Reading

- National Vulnerability Database - CVE-2017-3167
- Apache Security Advisories
- Red Hat Security Advisory

Summary

CVE-2017-3167 is an example of how using library functions out-of-sequence can have serious effects—like letting attackers bypass your site’s login checks. Keep your server updated, and check your modules for correct authentication practices. With a little careful code review, you can keep your servers safe.

Timeline

Published on: 06/20/2017 01:29:00 UTC
Last modified on: 06/06/2021 11:15:00 UTC