From ciac@rumpole.llnl.gov Sun Sep 5 01:54:36 1999 From: CIAC Mail User Resent-From: mea culpa To: ciac-bulletin@rumpole.llnl.gov Resent-To: jericho@attrition.org Date: Fri, 3 Sep 1999 14:54:10 -0700 (PDT) Subject: CIAC Bulletin J-063: Domain Name System (DNS) Denial of Service (DoS) Attacks [ For Public Release ] -----BEGIN PGP SIGNED MESSAGE----- __________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN Domain Name System (DNS) Denial of Service (DoS) Attacks September 1, 1999 17:00 GMT Number J-063 ______________________________________________________________________________ PROBLEM: A new form of denial of service attack based on the difference in size between a Domain Name System (DNS) query and a DNS response and the willingness of DNS servers to answer queries from any source. PLATFORM: Any DNS server. DAMAGE: This vulnerability may allow remote denial of service attacks against target hosts whose IP addresses are spoofed in the DNS query. SOLUTION: Apply workarounds. ______________________________________________________________________________ VULNERABILITY Risk is high. The exploit for this vulnerability has been ASSESSMENT: made public. The workarounds should be applied as soon as possible. ______________________________________________________________________________ [ Start AUSCERT Advisory ] =========================================================================== A U S C E R T A L E R T AL-1999.004 -- AUSCERT ALERT Denial of Service (DoS) attacks using the Domain Name System (DNS) 13 August 1999 Last revised: 13 August 1999 A complete revision history is at the end of this file. =========================================================================== PROBLEM: AusCERT has received information about a new form of denial of service attack based on exploiting the difference in size between a Domain Name System (DNS) query and a DNS response and the willingness of DNS servers to answer queries from any source. This vulnerability may allow remote denial of service attacks against target hosts whose IP addresses are spoofed in the DNS query. Information regarding this vulnerability has been made publicly available and a tool has been posted to the BUGTRAQ mailing list which apparently exploits this vulnerability. AusCERT has been advised of sustained instances of the use of this tool to conduct denial of service attacks against sites within Australia. There are three parties: the target, the traffic multiplying DNS servers (amplifiers), and the attacker. Any platform connected to the Internet may be the target of the denial of service. Service is denied by occupying all link bandwidth with responses to bogus DNS queries and potential ICMP port unreachable responses to these bogus responses. Any DNS server may be used to multiply the denial of service attack. Usually several DNS servers on networks with good bandwidth to the target are required to effectively attack the target, however the same effects can be achieved by using a larger number of amplifiers with smaller bandwidth capabilities. The attack is launched from a remote location with moderate bandwidth to the amplifiers. IMPACT: Small DNS queries are sent from the attacker to each of the DNS servers. These queries contain the spoofed IP address of the target. The DNS servers respond to the small query with a large response. These responses are routed to the target, causing link congestion and possible denial of Internet connectivity. If the number of DNS queries from the attacker is large, then the traffic may congest the DNS server's Internet link or degrade the DNS server's response time. Although no different in principle from ICMP ECHO ("ping") flooding, DNS query traffic cannot be traffic-shaped by network routers without greatly inconveniencing legitimate users. Information regarding this vulnerability has been made publicly available. A tool to exploit this vulnerability was posted to the BUGTRAQ mailing list on 30 July 1999 by smaster@sail.it in message <199907310000.AA154206596@sail.it>. AusCERT members have observed this tool in use against hosts on their networks. SOLUTION: Since this attack relies upon spoofed source IP addresses, source address checking by ISPs originating traffic is the only means to entirely defeat this form of denial of service attack. Appendix A of CERT advisory CA96.21 "TCP SYN Flooding and IP Spoofing Attacks" gives more information on configuring networks to defeat IP address spoofing. That advisory is available from: http://www.cert.org/advisories/CA-96.21.tcp_syn_flooding.html Additional information may also be found in RFC2267 "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing". That RFC is available from your local RFC repository including: ftp://ftp.auscert.org.au/pub/mirrors/ftp.isi.edu/in-notes/rfc2267.txt WORKAROUND: The current tools and attacks are very straightforward and administrators can prevent their DNS servers from being used as amplifiers by configuring their servers to answer queries from unexpected sources with a small REFUSED response rather than a much larger name resolution response. [In the discussion below, "trusted" sources are defined as hosts for which the DNS server provides recursive DNS name resolution. These hosts would usually lie within an ISP's or enterprise's network. These hosts usually have the DNS server listed in a configuration file such as /etc/resolv.conf or supplied to it in a PPP, DHCP or BOOTP response.] For the purposes of refusing queries from unexpected sources, DNS queries directed to a particular name server can be categorised into the following types. For each type of query a typical access control configuration is given. In addition, we suggest controls for zone transfers. While restricting access to zone transfers is not directly related to the denial of service attack described in this alert, it may provide additional security for some sites. (1) QUERIES FOR ANY NAME. Allow queries from "trusted" sources only. Allow no zone transfers. (2) QUERIES FOR NAMES IN PRIMARY ZONES. A "primary zone" is a zone for which a server has the DNS master file described in RFC1035 and the server is one of the name servers that has been delegated the domain. Allow queries from all sources. Allow zone transfers from official and stealth secondaries. (3) QUERIES FOR NAMES IN OFFICIAL SECONDARY ZONES. An "official secondary zone" is a zone for which the server has a zone transfer of the DNS master file and is one of the name servers that has been delegated the domain. Official secondary zones exist to add robustness to the Domain Name System. Allow queries from all sources. Possibly allow zone transfers from official and stealth secondaries. (4) QUERIES FOR NAMES IN STEALTH SECONDARY ZONES. A "stealth secondary zone" is a zone for which the server has a zone transfer of the DNS master file but is not one of the name servers that has been delegated the domain. Stealth secondary zones are often used to add performance to DNS resolution, especially at sites reachable only across slow wide-area network links or on machines containing DNS-intensive applications such as e-mail. Allow queries from "trusted" sources only. Allow no zone transfers. It may be administratively convenient to allow queries from all sources, as this minimises the risk of outages if official secondary zones and stealth secondary zones are confused or if all the users of the stealth secondary zone are not known. If queries are limited to "trusted" sources only, then a careful eye should be kept on the DNS server log. An exception to the guidelines in (2) to (4) above is that within the configuration of each DNS server a sub-domain cannot service a smaller range of query sources than its parent domain. If a DNS server allows queries from any source for the domain "example.com", then it must also allow queries from any source for the delegated sub-domain "instructive.example.com". It is administratively useful to allow DNS zone transfers between all primary and secondary DNS servers. This eases the debugging of zone transfer faults. Similarly, allowing DNS zone transfers to a limited number of hosts used by network administrators may also be convenient. Allowing zone transfers to all "trusted" users may be too trusting in environments such as Internet service providers or universities. "Stealth primary zones" also exist. As these are mainly used inside firewalled environments, it is not useful to describe their configuration in this document. LIMITATIONS: There are obvious limitations to the workarounds presented in this alert. As stated previously, the only solution to this problem currently is that all sites implement source address checking to prevent packets with spoofed IP addresses leaving their networks. Nonetheless, these suggestions will assist in mitigating current forms of the attack and may provide some additional security. BIND VERSION 8 EXAMPLE CONFIGURATION EXTRACTS: Internet Software Consortium's Berkeley Internet Name Domain is a popular DNS server for UNIX and other POSIX-like operating systems. This section implements the above recommendations for BIND version 8.2.1. The current release of BIND (including source code) and other information is available at the ISC webpage: http://www.isc.org/view.cgi?/products/BIND/index.phtml BIND 8.2.1 is also available directly via ftp from: ftp://ftp.isc.org/isc/bind/src/8.2.1/ ftp://ftp.auscert.org.au/pub/mirrors/ftp.isc.org/bind/src/8.2.1/ Earlier releases of BIND are vulnerable to the faults listed in CERT Summary CS98.05 (redistributed as AusCERT ESB-98.080). At the time of issue of this document, ISC recommends upgrading to BIND 8.2.1. A C source code patch must be applied to all BIND 8.2.1 servers for the configuration presented in this section to operate correctly. This unsupported patch to BIND version 8.2.1 prevents BIND returning REFUSED when it should be returning a referral to a child zone. This patch is available from: ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.patch If you wish to check the integrity of the above patch file, please download the 'detached PGP signature' file from: ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.patch.asc and check it with the AusCERT public key available from: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key The security policy examples given in this alert are typical of a large university or ISP. They implement the suggested recommendations on access control as presented in the WORKAROUND section. It is noted where the security policy could be relaxed in a less internally hostile environment. Sites will, of course, need to modify the examples to match their own policies as appropriate. The examples in this section use a fictitious company with the domain name "example.com" and the fictitious IP address range 126.0.0.0/8. The BIND configuration file is called "/etc/named.conf". The configuration file may have some other name on your BIND server. When configuring a particular name server, first set the default level of query and zone transfer access as per the examples in (1) below. Then override this with specific access controls for each zone, according to its type (either (2) primary, (3) official secondary or (4) stealth secondary). Each section here implements the recommendations from the matching section number from WORKAROUND. (1) DEFAULT. The default case is handled by setting the BIND options. This is an extract from the file "/etc/named.conf" on all of "example.com"'s BIND DNS servers. // DNS clients at example.com acl "trusted" { localhost; 126.0.0.0/8; // Hosts at example.com }; // Known fake source addresses shouldn't be replied to. // For external queries, these should be blocked by // example.com's border router. acl "bogon" { 0.0.0.0/8; // Null address 1.0.0.0/8; // IANA reserved, popular fakes 2.0.0.0/8; 192.0.2.0/24; // Test address 224.0.0.0/3; // Multicast addresses // Enterprise networks may or may not be // bogus. 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; }; options { directory "/var/named"; allow-query { trusted; }; allow-transfer { none; }; blackhole { bogon; }; }; // Bootstrap the root. zone "." { type hint; file "named.ca"; }; // 127.0.0.0/24 The loopback network. zone "0.0.127.in-addr.arpa" { type master; file "127.in-addr.arpa"; allow-query { trusted; }; // Every DNS server should be a master // for 127.0.0.0/24. allow-transfer { none; }; }; (2) PRIMARY ZONES. "dns0.example.com" is the primary DNS server for the zone "example.com". This is an extract from the "/etc/named.conf" file on "dns0.example.com". The extract defines the zone "example.com" and lists the zone's secondary DNS servers. // Official and stealth secondaries. acl "example-xfer" { 126.0.2.2; // dns1.example.com (official) 126.0.1.1; // dns2.example.com (official) 126.0.3.4; // mailhub.example.com (stealth) }; zone "example.com" { type master; // official file "primary/example.com"; allow-query { any; }; allow-transfer { localhost; example-xfer; }; }; // 126.0.0.0/8 zone "0.126.in-addr.arpa" { type master; // official file "primary/0.126.in-addr.arpa"; allow-query { any; }; allow-transfer { localhost; example-xfer; }; }; As was noted above, any sub-domains of "example.com" present on this DNS server must allow queries from any source, as the parent domain on this server allows queries from any source. (3) OFFICIAL SECONDARY ZONES. "dns1.example.com" is an official secondary DNS server for the zone "example.com". This is an extract from the "/etc/named.conf" file on "dns1.example.com". The extract defines the zone "example.com". // Official and stealth secondaries. acl "example-xfer" { 126.0.2.2; // dns1.example.com (official) 126.0.1.1; // dns2.example.com (official) 126.0.3.4; // mailhub.example.com (stealth) }; zone "example.com" { type slave; // official file "secondary/example.com"; masters { 126.0.2.1; // dns0.example.com }; allow-query { any; }; allow-transfer { localhost; example-xfer; }; }; // 126.0.0.0/8 zone "0.126.in-addr.arpa" { type slave; // official file "secondary/0.126.in-addr.arpa"; masters { 126.0.2.1; // dns0.example.com }; allow-query { any; }; allow-transfer { localhost; example-xfer; }; }; As was noted above, any sub-domains of "example.com" present on this DNS server must allow queries from any source, as the parent domain on this server allows queries from any source. (4) STEALTH SECONDARY ZONES. "mailhub.example.com" is a stealth secondary DNS server for the zone "example.com". This is an extract from the "/etc/named.conf" file on "mailhub.example.com". The extract defines the zone "example.com". acl "trusted" { localhost; 126.0.0.0/8; // Hosts at example.com }; // Official and stealth secondaries. acl "example-xfer" { 126.0.2.2; // dns1.example.com (official) 126.0.1.1; // dns2.example.com (official) 126.0.3.4; // mailhub.example.com (stealth) }; zone "example.com" { type slave; // stealth file "secondary/example.com"; masters { 126.0.2.1; // dns0.example.com }; allow-query { trusted; // or "any;" if you don't have good records // of the expected users of the stealth // secondary. }; allow-transfer { localhost; example-xfer; }; }; // 126.0.0.0/8 zone "0.126.in-addr.arpa" { type slave; // stealth file "secondary/0.126.in-addr.arpa"; masters { 126.0.2.1; // dns0.example.com }; allow-query { trusted; // or "any;" if you don't have good records // of the expected users of the stealth // secondary. }; allow-transfer { localhost; example-xfer; }; }; As was noted above, any sub-domains of "example.com" present on this DNS server must allow queries from at least the hosts in the "trusted" access control list, as the parent domain on this server allows queries from that list. OTHER BIND VERSION 8 SECURITY OPTIONS: LIMITING VERSION NUMBER AVAILABILITY By default, the BIND version number can be read globally using a DNS query utility such as "dig": dig @dns0.example.com version.bind chaos txt Allowing the version number of any software to be known to everyone is usually undesirable. Access to the version number can be restricted to local users by adding the following to "/etc/named.conf" on all BIND DNS servers: // Control access to BIND version number to // users at example.com only. // Ref: BUGTRAQ posting from LaMont Jones // on 1998-06-12. zone "bind" chaos { type master; file "primary/bind"; allow-query { trusted; }; allow-transfer { none; }; }; and by also adding the file "/var/named/primary/bind" containing only: ; File /var/named/primary/bind $ORIGIN bind. @ 1D CHAOS SOA localhost. root.localhost. ( 1 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1D ) ; minimum CHAOS NS localhost. ; EOF CONTROLLING LOG MESSAGES When being used to vector an attack, the BIND DNS server can generate a large number of log messages of the form: unapproved query from [99.2.3.4].12345 for "example.net" The BIND DNS server can be configured to log these messages to a separate file, a separate syslog facility (allowing logging on a remote machine) or to discard all security messages. Unfortunately, discarding security messages also discards messages referring to users of stealth zones that have been accidently denied access and messages generated by the confusion of an official secondary zone with a stealth secondary zone. It would be wise to review the log messages for these events before considering disabling security event logging. CONTROLLING VISIBILITY OF DNS SERVERS: Not all DNS servers are known to ISPs or the network administrators of large enterprises. In particular, there is no simple means of determining the presence of caching-only DNS servers on hosts. These servers are usually not configured to regulate the source of DNS queries. As a result, these servers can be used to amplify DNS-based denial of service attacks even if all the DNS servers owned by the ISP regulate the source of DNS queries. Organisations should consider limiting DNS UDP and TCP access to just the known DNS servers by configuring access restrictions on their network's border router. These access restrictions can be summarised as: - servers containing primary or official secondary zones: Remote *:* <-> address:53 Local (UDP/TCP) - each DNS server that acts as a resolver (that is, is listed in /etc/resolv.conf or supplied by PPP, DHCP or BOOTP): Remote *:53 <-> address:* Local (UDP/TCP) or, if the DNS servers are configured with "query-source * port 53;": Remote *:53 <-> address:53 Local (UDP) Remote *:53 <-> address:* Local (TCP) - servers containing unofficial secondary zones have varying requirements, depending on the location of the primary zone server: Remote master:* <-> address:53 Local (UDP) (Notify) Remote master:53 <-> address:* Local (UDP) (SOA query) Remote master:53 <-> address:* Local (TCP) (IXFR) or, if the DNS servers are configured with "query-source * port 53;": Remote master:* <-> address:53 Local (UDP) (Notify) Remote master:53 <-> address:53 Local (UDP) (SOA query) Remote master:53 <-> address:* Local (TCP) (IXFR) There are two traps for access list authors. Firstly, any DNS UDP request may be given as a DNS TCP request. Secondly, the DNS NOTIFY command must be allowed for servers of primary zones to inform servers of secondary zones of a change in the master file. Implementing these access restrictions prevents queries from hosts inside the network and denies direct access from hosts inside the network to external name servers. Denying direct access is unlikely to affect most hosts: these make a recursive query to a pre-configured DNS server. Denying direct access to external name servers is likely to break caching-only DNS name servers on hosts. These servers can be reconfigured to forward DNS requests to one or more of the DNS servers that has DNS visibility to the Internet. A caching-only name server configuration for UNIX and other POSIX-like hosts running BIND version 8 is presented in Appendix A. APPENDIX A: ISC BIND 8.2.1 CACHING-ONLY NAME SERVER CONFIGURATION A BIND version 8 configuration extract for a caching-only name server designed to service only the host it is running on is given below. The DNS names and IP addresses used correspond to those in the section "BIND Version 8 Example Configuration Extracts" above. Extracts from file "/etc/named.conf": options { // "only" misleads -- if all the forwarders fail we // are no worse off than with only a /etc/resolv.conf, // but we get the benefit of DNS name caching in the // meantime. forward only; forwarders { // From previous "nameserver" entries in // /etc/resolv.conf. 126.0.2.1; // dns0.example.com 126.0.2.2; // dns1.example.com 126.0.1.1; // dns2.example.com }; allow-query { localhost; }; listen-on { // Ignore spoofed packets on externally // visible interfaces. 127.0.0.1; // loopback }; }; // Bootstrap the root. zone "." { type hint; file "named.ca"; }; // 127.0.0.0/24 The loopback network. zone "0.0.127.in-addr.arpa" { type master; file "127.in-addr.arpa"; allow-query { localhost; }; }; // Control access to BIND version number. zone "bind" chaos { type master; file "primary/bind"; allow-query { localhost; }; }; Complete file "/etc/resolv.conf": search example.com nameserver 127.0.0.1 - - ---------------------------------------------------------------------------- AusCERT would like to acknowledge Glen Turner of the University of Adelaide, who contributed a substantial volume of the information in this alert. Vital assistance and information was also provided by Mark Andrews of the Internet Software Consortium. Thanks is due to Alan Cowie of the NSW Regional Network Organisation for his feedback regarding this issue. AusCERT also wishes to thank Chris Teakle and Mark Suter of The University of Queensland for providing expert comments and feedback on the content of this alert. - - ---------------------------------------------------------------------------- [AusCERT issues an alert when the risk posed by a vulnerability that may not have been thoroughly investigated and for which a work-around or fix may not yet have been developed requires notification.] The AusCERT team has made every effort to ensure that the information contained in this document is accurate at the time of publication. However, the decision to use the information described is the responsibility of each user or organisation. The appropriateness of this document for an organisation or individual system should be considered before application in conjunction with local policies and procedures. AusCERT takes no responsibility for the consequences of applying the contents of this document. If you believe that your system has been compromised, contact AusCERT or your representative in FIRST (Forum of Incident Response and Security Teams). AusCERT maintains an anonymous FTP service which is found on: ftp://ftp.auscert.org.au/pub/. This archive contains past SERT and AusCERT Advisories, and other computer security information. AusCERT maintains a World Wide Web service which is found on: http://www.auscert.org.au/. Internet Email: auscert@auscert.org.au Facsimile: (07) 3365 7031 Telephone: (07) 3365 4417 (International: +61 7 3365 4417) AusCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for emergencies. Postal: Australian Computer Emergency Response Team The University of Queensland Brisbane Qld 4072 AUSTRALIA =========================================================================== Revision History: 13 Aug 1999 Corrected typographical errors in numbering of headers in "CONFIGURATION EXTRACTS" section. =========================================================================== [ End AUSCERT Advisory ] ______________________________________________________________________________ CIAC wishes to acknowledge AUSCERT for the information contained in this bulletin. ______________________________________________________________________________ CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy (DOE) and the emergency backup response team for the National Institutes of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. CIAC services are available to DOE, DOE contractors, and the NIH. CIAC can be contacted at: Voice: +1 925-422-8193 FAX: +1 925-423-8002 STU-III: +1 925-423-2604 E-mail: ciac@llnl.gov For emergencies and off-hour assistance, DOE, DOE contractor sites, and the NIH may contact CIAC 24-hours a day. During off hours (5PM - 8AM PST), use one of the following methods to contact CIAC: 1. Call the CIAC voice number 925-422-8193 and leave a message, or 2. Call 888-449-8369 to send a Sky Page to the CIAC duty person or 3. Send e-mail to 4498369@skytel.com, or 4. Call 800-201-9288 for the CIAC Project Leader. Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://www.ciac.org/ (or http://ciac.llnl.gov -- they're the same machine) Anonymous FTP: ftp.ciac.org (or ciac.llnl.gov -- they're the same machine) Modem access: +1 (925) 423-4753 (28.8K baud) +1 (925) 423-3331 (28.8K baud) CIAC has several self-subscribing mailing lists for electronic publications: 1. CIAC-BULLETIN for Advisories, highest priority - time critical information and Bulletins, important computer security information; 2. SPI-ANNOUNCE for official news about Security Profile Inspector (SPI) software updates, new features, distribution and availability; 3. SPI-NOTES, for discussion of problems and solutions regarding the use of SPI products. Our mailing lists are managed by a public domain software package called Majordomo, which ignores E-mail header subject lines. To subscribe (add yourself) to one of our mailing lists, send the following request as the E-mail message body, substituting ciac-bulletin, spi-announce OR spi-notes for list-name: E-mail to ciac-listproc@llnl.gov or majordomo@rumpole.llnl.gov: subscribe list-name e.g., subscribe ciac-bulletin You will receive an acknowledgment email immediately with a confirmation that you will need to mail back to the addresses above, as per the instructions in the email. This is a partial protection to make sure you are really the one who asked to be signed up for the list in question. If you include the word 'help' in the body of an email to the above address, it will also send back an information file on how to subscribe/unsubscribe, get past issues of CIAC bulletins via email, etc. PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained via WWW at http://www.first.org/. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC) J-053: HP Current Directory Vulnerability J-054: Unauthorized Access to IIS Servers through ODBC Data Access with RDS J-055: IBM AIX Vulnerability in ptrace() system call J-056: Microsoft "Encapsulated SMTP Address" Vulnerability J-057: Windows NT(r) Terminal Servers DOS Vulnerability J-058: Microsoft "Malformed HTTP Request Header" Vulnerability J-059: IBM AIX (pdnsd) Buffer Overflow Vulnerability J-060: Microsoft Office ^ÑODBC^Ò Vulnerabilities J-061: Lotus Notes Domino Server Denial of Service Attacks J-062: Netscape Enterprise and FastTrack Web Servers Buffer Overflow -----BEGIN PGP SIGNATURE----- Version: 4.0 Business Edition iQCVAwUBN86bCLnzJzdsy3QZAQE6NQP+KMaz2LfRLRc3WonEQk072+JrI8VR0MWA KPyaRmYmmimavRS6ung1anUBsuBZ1cRgB9gAXJ3vVOdElt6kSDXfn/tJIRmuDB++ FlTa/bFux8BRx35zM0+xqIkU5SSBGXqyUcS0r/CsCX4aY4f1YGR0D9LxAP5DBCsj 9tPnm8quxPM= =seVz -----END PGP SIGNATURE-----