Hi folks, I'm proposing some more words to head-off LLMs before/after they reach security@ with a clearer description of the security model for specific modules. I'd appreciate review particularly:
1) for mod_lua, I think we should be explicit that random module bugs (crashes, leaks etc) are outside the security model. It is too easy for LLMs to jump from remote unauthenticated client runs Lua script X, X has crash/bug/leak/whatever -> vulnerability - that isn't a sensible or sustainable model. 2) mod_proxy_hcheck/mod_proxy_beacon and mod_heartmonitor - is this all correct? Regards, Joe
Index: SECURITY.md =================================================================== --- SECURITY.md (revision 1939459) +++ SECURITY.md (working copy) @@ -27,7 +27,8 @@ Every vulnerability report MUST begin by either: a) clearly identifying the aspect of this security model which is -violated by the reported bug, or +violated by the reported bug, including any applicable +[module-specific trust boundary](#module-specific-trust-boundaries), or b) succinctly describing a trust boundary which is not covered by this document, supported by references (such as the httpd documentation), @@ -139,10 +140,13 @@ * configurations using deliberately constructed regular expressions which are expensive to evaluate -In configurations supporting in-process scripting language interpreters -which are not sandboxed, such as `mod_lua`, `mod_sed` or `mod_php`, -site authors have exactly equivalent privileges to the user which the -server runs as. +In configurations where `.htaccess` files can configure in-process +code execution which is not sandboxed, such as `mod_lua` (see the +[mod_lua](#mod_lua) section below), SSI documents with `Options +Includes`, or third-party interpreters such as `mod_php`, site authors +have exactly equivalent privileges to the user which the server runs +as. Site-author content which by design controls response +headers (`mod_asis` files) is trusted for HTTP framing. ## Trusted Services @@ -152,19 +156,273 @@ Examples of trusted services include, but are not limited to: -* Services used for caching privileged or protected data -* Database or LDAP servers used for authentication via `mod_ldap` or `mod_dbd` -* Redis/Valkey, or Memcache servers used for the `mod_ssl` session cache -* OCSP servers used for client certificate verification, or server certificate "stapling" -* ACME servers used for issuing certificate in `mod_md` -* PROXY protocol intermediaries used with `mod_remoteip` +* Services used for caching privileged or protected data, including + all `mod_socache_*` providers (memcached, Redis/Valkey, distcache, + shared memory, DBM) whether used for the `mod_ssl` session or + stapling cache, `mod_authn_socache` credentials, or `mod_cache_socache` +* Database or LDAP servers used for authentication, authorization or + session storage via `mod_dbd` or `mod_ldap`, including LDAP referral + targets when `LDAPReferrals` is enabled +* OCSP servers used for client certificate verification, or server + certificate "stapling", and CA/CRL/certificate/key files +* ACME servers used for issuing certificates in `mod_md` +* Intermediaries listed in `RemoteIPTrustedProxy`/`RemoteIPInternalProxy`, + and PROXY protocol senders (see `mod_remoteip` below) +* The local syslog, journald and systemd services +* External programs executed by the server as configured by the + administrator: piped loggers, `RewriteMap prg:`, `ExtFilterDefine`, + `SSLPassPhraseDialog exec:`, `mod_md` notification commands, CGI + programs and FastCGI/SCGI/uWSGI applications +* Loadable modules (`LoadModule`) and ISAPI extensions -Backend servers are those accessed in a reverse proxy (or gateway) -configuration, typically via HTTP or AJP (see +Backend servers are those explicitly configured by the administrator +in a reverse proxy (or gateway) configuration, typically via +`ProxyPass`, `ProxyPassMatch`, `BalancerMember` or `RewriteRule [P]`, +using HTTP, HTTP/2, AJP, FastCGI, SCGI or uWSGI (see https://httpd.apache.org/docs/current/mod/mod_proxy.html#forwardreverse). -Backend servers are trusted to provide content but SHOULD NOT be able -to influence HTTP protocol framing logic in the frontend (client) -communication (so called "response splitting" attacks). +Backend servers are trusted to provide content and response headers, +and bugs triggered only by a malicious backend are outside the model, +with one exception: backends SHOULD NOT be able to influence HTTP +protocol framing logic in the frontend (client) communication (so +called "response splitting" attacks). +Origin servers contacted in a *forward* proxy configuration +(`ProxyRequests On`, `CONNECT` tunnels via `mod_proxy_connect`, and FTP +servers via `mod_proxy_ftp`) are NOT trusted; they are arbitrary +network peers and are covered by the basic model. + Example vulnerabilities which violated the model: CVE-2026-33523, CVE-2024-42516. + +## Module-specific trust boundaries + +The following describes trust boundaries specific to individual +modules, in addition to the general model above. + +### Administrative handlers + +The `balancer-manager` (`mod_proxy_balancer`), `server-status` +(`mod_status`), `server-info` (`mod_info`), `ldap-status` (`mod_ldap`) +and `md-status` (`mod_md`) handlers expose privileged information or +allow runtime reconfiguration. They MUST be protected by access +control, as described in each module's documentation. Any user granted +access to these handlers is trusted as an administrator; in particular +a `balancer-manager` user can direct traffic to arbitrary backends. +Disclosure resulting from enabling these handlers without access +control, including via `SetHandler` in `.htaccess`, is a configuration +error. The nonce and Referer checks in `balancer-manager` defend an +authorized operator against cross-site request forgery only. + +### mod_sed, mod_substitute, mod_ext_filter + +The sed script configured via `InputSed`/`OutputSed`, the `Substitute` +pattern and replacement, and the program configured via +`ExtFilterDefine` are trusted input. `mod_sed` scripts can read and +write any file accessible to the server user (`r` and `w` commands); +`InputSed`/`OutputSed` are not available in `.htaccess`. `Substitute` +is available to `.htaccess` authors, who are trusted per the Delegated +Configuration section. The content filtered (request and response +bodies) is untrusted and MUST be handled safely by the filters. + +### mod_proxy_hcheck + +Health checks are sent to configured backends, which are trusted as +described under Trusted Services. Defects triggered only by a +malicious or malformed health-check response are outside the model. +The limits on health-check processing described in the module +documentation are robustness measures and are not a security +guarantee. + +### mod_proxy_scgi + +With `ProxySCGISendfile` the backend may direct the server to serve any +file readable by the server user, and with `ProxySCGIInternalRedirect` +(the default) any internal URL. This is by design: SCGI backends are +trusted at the level of the server user. + +### mod_proxy_wstunnel, mod_proxy_connect, mod_proxy_fdpass + +Once a protocol upgrade (101) is accepted from a configured backend, +or a `CONNECT` tunnel is established, bytes are relayed without +interpretation; the content of the tunnel is outside the model and +only timeouts apply. `CONNECT` targets are untrusted peers (see Trusted +Services). A process receiving client sockets via `mod_proxy_fdpass` +owns the connection thereafter and is fully trusted. + +### mod_proxy_beacon, mod_heartbeat, mod_heartmonitor + +Holders of the `ProxyBeaconSecret` are trusted as balancer +administrators. Datagrams which fail authentication or freshness +checks are untrusted network input and MUST have no effect beyond +logging. `mod_heartmonitor` accepts *unauthenticated* status packets: +it MUST only be enabled on a network segment where every host able to +send to the listening address is trusted, and heartbeat data may only +influence load distribution among configured members. + +### mod_remoteip + +Client addresses asserted by proxies listed in `RemoteIPTrustedProxy` +or `RemoteIPInternalProxy` are trusted; spoofing by such a proxy is +out of scope, as is spoofing by any client when `RemoteIPHeader` is +used without a trusted proxy list (a documented misconfiguration). +Assertions from unlisted peers MUST be ignored. Listeners enabled with +`RemoteIPProxyProtocol` MUST be reachable only by the intermediaries +expected to send the PROXY protocol header; under that configuration +the PROXY header is trusted input. + +### mod_cgi, mod_cgid, mod_suexec, mod_actions, mod_include + +CGI programs, SSI documents with `exec` enabled, and programs invoked +via `Action`/`Script` are trusted code running as the server user (or +the `suexec` target user). Their output is trusted content but, by +default, is not trusted to control HTTP framing: `Content-Length` is +recomputed unless `ap_trust_cgilike_cl` is set and `Transfer-Encoding` +is rejected. The `mod_cgid` socket is accessible only to the server +user; processes already running as that user are within the same trust +domain. The `suexec` wrapper trusts only the server user as caller and +enforces the checks documented at +https://httpd.apache.org/docs/current/suexec.html; a target user's own +insecure scripts are out of scope. + +### mod_lua + +Lua scripts, and anyone able to configure them (including `.htaccess` +authors where `AllowOverride` permits the `Lua*` directives, per +[Delegated Configuration](#delegated-configuration)), are trusted with +the full privileges of the server user. mod_lua provides +no sandbox: scripts may use the `os` and `io` libraries, read and +modify server configuration via `r:config()` and the request object, +and share Lua state across requests under `LuaScope thread` or +`server`. Consequently the following are NOT vulnerabilities: any +crash, hang, resource exhaustion or disclosure caused by a script's +own actions, including calling API functions with undocumented +argument types or values, requesting unbounded allocations, or +leaking data between scripts, requests or virtual hosts through a +shared Lua state. + +Scripts are responsible for bounding client-derived data they pass to +the API, for example via the `sizeLimit` argument of `r:parsebody`; +memory use proportional to a limit the script chose is by design. + +Every mod_lua code path runs on behalf of a remote client, so that a +client request triggers a defect establishes nothing by itself. +Ordinary robustness bugs in mod_lua's own bindings - including, but not +limited to, memory leaks, crashes, hangs and other resource exhaustion +- are treated as ordinary bugs, not security vulnerabilities, however +they are reached; a report MUST demonstrate a security outcome beyond +the crash or leak itself, such as memory corruption a client can +leverage for code execution or a bypass of access control. + +The non-default long-lived `LuaScope server`, `thread` and `conn` +settings share one Lua VM across requests, and `server`/`thread` are +documented as not thread-safe. A VM that outlives the request it was +used for, together with any request-bound object retained in it across +requests (the request userdata, a request-derived table, a database +result or prepared statement), is a script-lifecycle hazard owned by +the trusted author of the configuration. Stale-pointer crashes, +cross-request disclosure and memory corruption which depend on one of +these scopes are therefore out of scope; the default `LuaScope once` +gives each request a fresh VM. + +Reports MUST include the triggering Lua script and show that it is one +a careful author following the documentation would write. + +### mod_rewrite + +Rewrite rules and all `RewriteMap` sources (`txt`, `dbm`, `rnd`, +`prg`, `dbd`/`fastdbd`) are trusted configuration; `prg` maps run with +the privileges of the user who started the server unless configured +otherwise. Rules which pass unconstrained client input to redirect, +proxy or filesystem targets are configuration errors, as described in +the documentation. The module's default protections (such as +`AllowAnyURI` being off, and the `UnsafeAllow3F`/`UnsafePrefixStat` +flags being required) are part of the model and their bypass is in +scope. + +### mod_ssl, mod_md + +Certificate, key, CA, CRL and OpenSSL configuration files and +`SSLOpenSSLConfCmd` are trusted. Client certificate data is untrusted +input; identity derived from it is meaningful only when verification +succeeds against a configured CA, and `SSLVerifyClient optional_no_ca` +provides no authentication. TLS to backends authenticates the backend +only with `SSLProxyVerify require`. In `mod_md`, requests to the ACME +challenge paths, `acme-tls/1` handshakes and the public +`certificate-status` handler are untrusted client input; the ACME +server, `MDStoreDir`, and the commands configured via +`MDChallengeDns01`, `MDMessageCmd` and `MDNotifyCmd` are trusted. + +### mod_session, mod_session_cookie, mod_session_crypto, mod_auth_form + +A session stored in a client cookie without `mod_session_crypto` is +fully client-controlled and provides neither confidentiality nor +integrity; treating its contents as authentic is a configuration +error. With `mod_session_crypto`, forging a session without the key is +in scope. Backends and scripts able to set `SessionHeader` are trusted +to write sessions. `mod_auth_form` re-verifies session credentials on +each request; the documented risks of inline login forms and of the +`AuthFormSitePassphrase` with unencrypted sessions are out of scope. + +### mod_dav, mod_dav_fs + +The DAV repository, lock database and property databases are private to +the server; modification outside httpd is unsupported. Authorized DAV +users are untrusted for protocol parsing, memory safety and path +confinement, but the documented denial-of-service possibilities open +to authorized users (filling the disk, `DavDepthInfinity`, +`DavHonorMtimeHeader`) are out of scope. + +### mod_cache, mod_cache_disk + +Cached content from reverse-proxy backends is trusted as provided. The +on-disk cache is writable by the server user and tampering with it +requires that privilege. Cache poisoning via the origin (DNS poisoning, +request smuggling against the origin) and the documented effects of +`CacheQuickHandler On` on per-directory access control are out of +scope. + +### mod_mime_magic, mod_mime_libmagic + +The magic database file is trusted configuration. The file content +examined may be untrusted (for example uploaded files) and the built-in +matcher MUST handle it safely. The risks of `MimeMagicDecompression` +(off by default) are documented and out of scope; defects in libmagic +itself are third-party. + +### mod_ident, DNS + +The RFC 1413 "ident" service queried by `mod_ident` runs on the +client's own host and is untrusted; its response is client input and +the documentation states it is not reliable. Reverse DNS results are +controlled by the owner of the client address and are untrusted; the +server performs double-reverse lookups for `Require host`. The +configured DNS resolver, and forward DNS used when parsing the +configuration, are trusted services (see +https://httpd.apache.org/docs/current/dns-caveats.html). + +### Authentication providers + +Credential and group stores used by authentication and authorization +providers (`htpasswd`/DBM files, SQL via `mod_dbd`, LDAP, FastCGI +authorizers via `mod_authnz_fcgi`, cached credentials via +`mod_authn_socache`, JWT signing keys for `mod_autht_jwt`) are trusted. +Credentials and tokens presented by clients are untrusted. Configuring +`AuthtJwtVerify none` delegates trust to the transport. + +### Logging + +Log files, their directories and piped log programs (which run as the +user who started the server) are trusted. Client-supplied data written +to logs is escaped as documented; a client able to inject raw control +characters or forge log lines via an escaped format field violates the +model. + +Example vulnerabilities which violated the model: CVE-2003-0083, +CVE-2003-0020, CVE-2013-1862, CVE-2024-47252. + +### Debugging, example and experimental modules + +The following are out of scope regardless of build configuration: +`mod_bucketeer`, `mod_dumpio`, `mod_firehose`, `mod_log_debug`, +`mod_echo`, `mod_dialup`, `mod_noloris`, `mod_serf`, and all modules +under `modules/examples` and `modules/test`.
