full-disclosure - Additional Details of Apache 2.x Security Flaw (Attack Vectors)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Additional Details of Apache 2.x Security Flaw (Attack Vectors)

After additional analysis of the Apache 2.x vulnerability described in
iDEFENSE advisory #053003 (APR vulnerability), I have found additional
modules associated with Apache that are vulnerable to this exploit.  Users
running any of the following:

mod_alias**
mod_dav/mod_dav_fs
mod_dir**
mod_imap**
mod_proxy
mod_rewrite*
mod_speling**
mod_ssl*
mod_usertrack*

should upgrade to the newest APR, shipped with Apache 2.0.46.  Exploits are
being tested for all of the above.  Two Apache API procedures are also
vulnerable:

ap_construct_url()*
ap_construct_server()*

* This requires UseCanonicalName Off or a name-based virtual host system for
successful exploitation.  Setting "UseCanonicalName On" eliminates this.
This is the default in some vendor packages.

** This requires the rare combination of UseCanonicalName Off and a
non-standard port.  The default is to install with UseCanonicalName Off,
although some vendor packages modify this.  Also, the Win32 installer allows
for listening on port 8080, and non-root users are usually forced to do this
on UNIX-based platforms.

It should also be noted that binary distributions may ship without mod_ssl,
preventing exploitation via this avenue.  Note that in this particular case,
UseCanonical Off is the only setting required and *not* wildcard DNS as was
required by CAN-2002-0840, as the user may submit whatever "Host" they like
directly via a telnet session -- a much less restrictive environment than an
XSS exploit.

WORKAROUNDS

* UseCanonicalName Off in the master configuration prevents many of these
issues.  Mod_proxy and mod_dav/mod_dav_fs are still exploitable with this
change.

* mod_dav: Setting LimitXMLRequestBody to less than 10000 will eliminate
this flaw, in combination with the previous workarounds.

* mod_proxy: Disable HTTP proxying.

The combination of these effectively prevents exploitation of all *known*
attack vectors.  Administrators are still encouraged to upgrade, as other
attack vectors may exist.  This vulnerability has the (theoretical)
possibility of arbitrary code execution, making it imperative that
vulnerable systems be upgraded at the earliest opportunity.