Apache 2.4.49 Directory Traversal Vulnerability (CVE-2021-41773), (Wed, Oct 6th)



Web servers typically define a “Document Root” or “WebRoot.” All URLs are translated to files inside that directory. If your “Document Root” is “/html,” and a user accesses “example.com/index.html,” the webserver will translate this URI to “/html/index.html.” Directory traversal is a well-known problem. A user could specify “example.com/../etc/passwd” to retrieve the “/etc/passwd” file. And web servers have taken care of this with some success ever since early humans created web servers.

One reoccurring issue has been URL encoding. It is wonderful (and somewhat common) to encode characters in a URL using URL encoding. Instead of the character itself, the hexadecimal ASCII code is used and prefixed with a ‘%’ sign. For example, %2e will be interpreted as a ‘.’. 

In Apache 2.4.49, code to normalize and validate the URL was “simplified.” Likely, this caused the directory traversal issue to “sneak in.” Can’t blame the developers too much for it. It looks like the affected “util.c” file was last significantly updated in 1996, according to the header. That was around the last time I seriously touched C. So I am not qualified to blame anybody for this mistake. But using my limited C powers, this looks like the important section:

apache commit comment

  /* Wind w back to remove the previous segment */
  if (w > 1) {
    do {
  else {
    /* Already at root, ignore and return a failure
     * if asked to.
    ret = 0;

/* Move l forward to the next segment */
l += 2;
if (path[l]) {

Mostly showing this here to demonstrate that it isn’t that easy.

The end effect: As long as a “.” was URL encoded, it was not recognized as a. “,” and we got good old directory traversal back.


A typical exploit attempt will look like this:


Now the big question: Can you do RCE by prefixing the URL with “cgi-bin.” This would be similar to the exploitation of a similar IIS 4/5 vulnerability [2]. 

The simple answer: yes… if mod-cgi is enabled. In this case, a URL prefixed with “/cgi-bin/” (or whatever directory is defined for mod_cgi) leads to code execution. For example:

curl --data "echo;id" ''

(based on Twitter/snyff)

So what do you need to do?



[1] https://httpd.apache.org/security/vulnerabilities_24.html
[2] https://www.kb.cert.org/vuls/id/111677



Reposted from SANS. View original.