httpd mod_auth directory protection bypassed by request path casing on case-insensitive filesystems

Improper Handling of Case Sensitivity vulnerability in Erlang/OTP inets httpd allows a remote unauthenticated attacker to read files inside a mod_auth protected directory by requesting them with different casing, on deployments whose filesystem is case-insensitive.

mod_auth:secret_path/3 decides whether a resolved filesystem path lies inside a protected directory block by running the configured directory path through re:run/3 without the caseless option. A request for /secret/file against a directory configured as /Secret therefore does not match, so the request is treated as unprotected and no authentication challenge is issued, while the filesystem resolves the differently cased path to the same file and mod_get serves it. Deployments on case-sensitive filesystems are unaffected, because there the filesystem itself rejects the mismatched casing.

This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.

• Host the document root on a case-sensitive filesystem, where the mismatched casing does not resolve to the protected file.
• Place a reverse proxy in front of httpd that performs its own case-insensitive path matching for the protected paths, or that normalises request path casing before forwarding.
• Restrict access to the server to trusted clients where the deployment allows it.

Two conditions must both hold. The server must protect a directory with mod_auth, by configuring a directory block with authentication requirements, and the document root must sit where the operating system resolves paths case-insensitively, which is the default on Windows and on macOS. Deployments whose path resolution is case-sensitive are unaffected.