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. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
This archive was generated by hypermail 2b30 : Fri May 30 2003 - 23:32:52 PDT