Security Advisories
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
-----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT* Vendor-Initiated Bulletin VB-98.02 Jan. 20, 1998 Topic: Apache Security Advisory Source: Marc Slemko, Apache Team Member <This email address is being protected from spambots. You need JavaScript enabled to view it.> To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Marc Slemko of Apache. Apache urges you to act on this information as soon as possible. Apache contact information is included in the forwarded text below; please contact them if you have any questions or need further information. =======================FORWARDED TEXT STARTS HERE============================ APACHE SECURITY ADVISORY Release Date: Tuesday, January 6 1998 Topic: Possible security issues with Apache in some configurations Summary of Issues ============================================================ This advisory is to inform all Apache users of several possible security issues that have been discovered during an internal security review of the Apache source code. DO NOT BE ALARMED BY THIS ADVISORY. This is a pro-active step designed to be certain that users of Apache are advised of the issues and can take appropriate action to minimize their risk. None of these holes allow for a root compromise (they only impact the user Apache runs as, as set with the "User" directive; if you have this user set to root, then fix your configuration now because you probably have a gaping security hole) and they generally require that a user already have access to the system before they can exploit them, meaning that on a large number of systems they are of little practical concern. Some of the issues that have been addressed might not be exploitable in real-world conditions. In some security environments, however, they may be of more concern. The administrator of the system running Apache is the only one who can make the judgment call as to how significant the below issues are in their environment. Resolution of Problems ====================== We very strongly recommend that anyone using versions of Apache previous to 1.2 or earlier 1.2 versions upgrade to the newly released 1.2.5. It is now available at http://www.apache.org/dist/ There are no plans for an immediate 1.3b4 release to correct these problems in the 1.3 beta development tree, however we will make patches for 1.3b3 to correct these issues available at http://www.apache.org/dist/patches/apply_to_1.3b3/ in the near future. Technical Description of Issues =============================== Below is a step by step technical description of the potential problems discovered. Read the below only if you wish to understand the details of the problems to better judge how they impact your server and if you have a solid grounding in how Apache works. If in doubt, you are advised to simply upgrade to 1.2.5 as soon as practical. I. Buffer overflow in cfg_getline() RISK: medium cfg_getline() is a function that the Apache core and several Apache modules use to read certain types of files from disk. Some examples of the type of files that read with this are htaccess, htpasswd and mod_imap files. It is possible to create a sequence of data such that a buffer overflow occurs while cfg_getline is reading from a file. If someone has access to create any of these types of files on the server, this hole is generally exploitable to gain full access to the user Apache runs as. On most systems, this is of little consequence since users already have such access via methods such as the creation of their own CGI scripts. If, however, the server is secured so that the user has no access to the server other than to create and modify files (eg. a "ftp only" account with no ability to create CGI scripts) this could allow increased access to the server. II. Several coding errors in mod_include RISK: medium There are several coding problems in mod_include which can result in a buffer overflow or in the child process going into an infinite loop. The same comments about the nature of the risk apply here as do for the cfg_getline() overflow. Generally, a user already needs to have access to the server to exploit this. Note that it is possible to setup a document which deliberately allows this to be remotely exploited, however such a document would be very rare in practice. If you do not allow users to use mod_include, then they can not exploit these holes. III. Inefficient removal of duplicate '/'s ("beck" exploit) RISK: medium The code in the no2slash() function used to collapse multiple '/'s in a request for access checking purposes is very inefficient. It is O(n^2) in the number of '/'s in the input. What this means is that as the input size grows, it very quickly requires vastly increased CPU time to process the request. By sending many requests with a large number of '/'s in to a server, it is possible to cause a large amount of CPU time to be used in processing these requests. Making multiple simultaneous requests of this nature could result in a high load average, high CPU usage, and possibly starving other processes for CPU resulting in a denial of service attack. This does not allow for any compromise of the server. The fixed version of the no2slash() function is O(n) and does not allow for this attack. Thanks to Michal Zalewski <This email address is being protected from spambots. You need JavaScript enabled to view it.> for discovering this bug and reporting it on the BUGTRAQ mailing list along with the "beck" script that can be used to exploit it. IV. Possible buffer overflow in "logresolve" program. RISK: low The logresolve program is used for non-realtime processing of logfiles to convert numeric IP addresses into host names. In some cases, it may be possible for a remote user who has control of a DNS server to return a hostname specifically designed to exploit a coding hole in logresolve. This can only happen on a system where either the MAXDNAME define does not exist and the resolver can return names longer than 256 characters or where the MAXDNAME define does exist but is less than the maximum length of hostname that the resolver can return. Even on such (arguably broken) systems, this would be very difficult to exploit. The number of systems which are impacted by this is very small. This problem is a potential concern only if you use the logresolve program. V. Insufficient data validation in mod_proxy RISK: low The ftp proxy part of mod_proxy accepts directory listings from remote ftp servers and converts them to HTML to send to the client. It is possible to deliberately create a listing that will cause Apache to dump core. This hole does not compromise the server; the only risk is that it would be possible to use this to create a denial of service attack which would render the server effectively inoperative. If you do not use mod_proxy, you are not vulnerable to this. If you restrict the use of mod_proxy, then only those users who are permitted to use it can attempt to exploit this problem. VI. Possible buffer overflow reading from the proxy cache RISK: low When caching is enabled in mod_proxy, Apache writes cached files to disk as the user that the server runs as. If an attacker can gain access to this user id (eg. by running a CGI script from a pre-existing account on the machine) then they can modify the filenames on disk resulting in a buffer overflow. Because the data is limited to what can be stored in a filename (not the file, just the filename), and they already need to have access to the user ID the server runs as to exploit this, the risk is minimal. The main instance where this may be a cause for concern is if there is privileged information stored in memory by the web server, such as an unencrypted SSL key. This same caution, however, applies to the other buffer overflows listed. If you do not use mod_proxy, this problem can not be exploited. VII. Unreadable htaccess files were ignored RISK: low Previously, if a htaccess file was unreadable Apache ignored it. This is, from a security standpoint, a poor idea because it goes against the principle of "if in doubt, deny access". This had already been corrected in the 1.3 development tree, but we had refrained from making the change in 1.2 because it could cause unexpected behavior on existing sites. We have since reconsidered, and as of 1.2.5, Apache will now reject requests if there is a htaccess file present in the relevant directory tree that is unreadable for any reason. It is also possible, in very rare conditions, for this to to be used to bypass htaccess files restricting access to a directory or file. The only case where this can happen is if the attacker can form a request that results in the full path to the htaccess file being too long (on most systems, meaning over 1024 characters) yet the request for the protected file in the same directory is not too long. The only normal case where such an attack could be possible is if there is a symbolic link such as "somedir -> ." created in the document tree. Contact Information =================== Full information about Apache and the 1.2.5 release which fixes these issues is available at http://www.apache.org/ Normal bugs can be reported via http://www.apache.org/bug_report.html If you believe you have discovered a security hole in Apache, please be sure to contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. so that we can verify and resolve the problem. Support questions to this address will not get a response. We fully support the concept of full disclosure, however it is always preferable to try to work with the vendor first before publicizing information about security holes. - -- Marc Slemko | Apache team member This email address is being protected from spambots. You need JavaScript enabled to view it. | This email address is being protected from spambots. You need JavaScript enabled to view it. ========================FORWARDED TEXT ENDS HERE============================= If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). See http://www.first.org/team-info/. We strongly urge you to encrypt any sensitive information you send by email. The CERT Coordination Center can support a shared DES key and PGP. Contact the CERT staff for more information. Location of CERT PGP key ftp://ftp.cert.org/pub/CERT_PGP.key CERT Contact Information - ------------------------ Email This email address is being protected from spambots. You need JavaScript enabled to view it. Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST (GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA CERT publications, information about FIRST representatives, and other security-related information are available from http://www.cert.org/ ftp://ftp.cert.org/pub/ CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce To be added to our mailing list for CERT advisories and bulletins, send your email address to This email address is being protected from spambots. You need JavaScript enabled to view it. In the subject line, type SUBSCRIBE your-email-address * Registered U.S. Patent and Trademark Office. The CERT Coordination Center is part of the Software Engineering Institute (SEI). The SEI is sponsored by the U. S. Department of Defense. This file: ftp://ftp.cert.org/pub/cert_bulletins/VB-98.02.apache -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNMT12nVP+x0t4w7BAQGHJAP/SdyVud0/zd32blZz6C6Dn+Q4KEmkuo+p h9lkJGqRj+dLMDS7fXEG3U2yfst8oTleoQ6crsapk0wRalCeKDJpUSL7V5rOgPQB YneEv9AAgnAbXWOg+BsfgGS2MQ1nOMECX4y6nNM79oYLs9woxNbnq5kvo44bjuhz 8wGb54+vWUY= =kByn -----END PGP SIGNATURE-----
| Powered by: | MHonArc  |
