1998 CERT Advisories

1998 CERT Advisories CERT Division [DISTRIBUTION STATEMENT A] Approved for public release and unlimited distribution. http://www.sei.cmu.edu REV-03.18.2016.0 Copyright 2017 Carnegie Mellon University. All Rights Reserved. This material is based upon work funded and supported by the Department of Defense under Contract No. FA8702-15-D-0002 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The view, opinions, and/or findings contained in this material are those of the author(s) and should not be con- strued as an official Government position, policy, or decision, unless designated by other documentation. References herein to any specific commercial product, process, or service by trade name, trade mark, manu- facturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by Carnegie Mellon University or its Software Engineering Institute. This report was prepared for the SEI Administrative Agent AFLCMC/AZS 5 Eglin Street Hanscom AFB, MA 01731-2100 NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. [DISTRIBUTION STATEMENT A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for non-US Government use and distribution. This material may be reproduced in its entirety, without modification, and freely distributed in written or elec- tronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at [email protected]. CERT® and CERT Coordination Center® are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. DM17-0052 1998 CERT ADVISORIES | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY [DISTRIBUTION STATEMENT A] Approved for public release and unlimited distribution. Table of Contents 1 CA-1998-01: Smurf IP Denial-of-Service Attacks 1 2 CA-1998-02: Vulnerabilities in CDE 9 3 CA-1998-03: Vulnerability in ssh-agent 14 4 CA-1998-04: Microsoft Windows-based Web Servers access via long file names 17 5 CA-1998-05: Multiple Vulnerabilities in BIND 21 6 CA-1998-06: Buffer Overflow in NIS+ 33 7 CA-1998-07: Vulnerability in Some Usages of PKCS#1 37 8 CA-1998-08: Buffer Overflows in Some POP Servers 42 9 CA-1998-09: Buffer Overflow in Some Implementations of IMAP Servers 46 10 CA-1998-10: Buffer Overflow in MIME-aware Mail and News Clients 54 11 CA-1998-11: Vulnerability in Tooltalk RPC Service 61 12 CA-1998-12: Remotely Exploitable Buffer Overflow Vulnerability in mountd 67 13 CA-1998-13: Vulnerability in Certain TCP/IP Implementations 72 1998 CERT ADVISORIES | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY i [DISTRIBUTION STATEMENT A] Approved for public release and unlimited distribution. 1: CA-1998-01: Smurf IP Denial-of-Service Attacks 1 CA-1998-01: Smurf IP Denial-of-Service Attacks Original issue date: January 5, 1998 Last revised: March 13, 2000 Added pointer to RFC2644/BCP34. A complete revision history is at the end of this file. This advisory is intended primarily for network administrators responsible for router configura- tion and maintenance. The attack described in this advisory is different from the denial-of-service attacks described in CERT advisory CA-97.28. The CERT Coordination Center has received reports from network service providers (NSPs), In- ternet service providers (ISPs), and other sites of continuing denial-of-service attacks involving forged ICMP echo request packets (commonly known as "ping" packets) sent to IP broadcast addresses. These attacks can result in large amounts of ICMP echo reply packets being sent from an intermediary site to a victim, which can cause network congestion or outages. These attacks have been referred to as "smurf" attacks because the name of one of the exploit programs attackers use to execute this attack is called "smurf." The CERT/CC urges you to take the steps described in Section III to reduce the potential that your site can be used as the origination site (Sec. III.C) or an intermediary (Sec. III.A.) in this attack. Although there is no easy solution for victim sites, we provide some recommendations in Sec. III.B. We will update this advisory as we receive additional information. Please check our advisory files regularly for updates that relate to your site. I. Description The two main components to the smurf denial-of-service attack are the use of forged ICMP echo request packets and the direction of packets to IP broadcast addresses. The Internet Control Message Protocol (ICMP) is used to handle errors and exchange control messages. ICMP can be used to determine if a machine on the Internet is responding. To do this, an ICMP echo request packet is sent to a machine. If a machine receives that packet, that machine will return an ICMP echo reply packet. A common implementation of this process is the "ping" command, which is included with many operating systems and network software packages. ICMP is used to convey status and error information including notification of network congestion and of other network transport problems. ICMP can also be a valuable tool in diagnosing host or network problems. 1998 CERT ADVISORIES | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 1 [DISTRIBUTION STATEMENT A] Approved for public release and unlimited distribution. 1: CA-1998-01: Smurf IP Denial-of-Service Attacks On IP networks, a packet can be directed to an individual machine or broadcast to an entire network. When a packet is sent to an IP broadcast address from a machine on the local network, that packet is delivered to all machines on that network. When a packet is sent to that IP broadcast address from a machine outside of the local network, it is broadcast to all machines on the target network (as long as routers are configured to pass along that traffic). IP broadcast addresses are usually network addresses with the host portion of the address having all one bits. For example, the IP broadcast address for the network 10.0.0.0 is 10.255.255.255. If you have subnetted your class A network into 256 subnets, the IP broadcast address for the 10.50 subnet would be 10.50.255.255. Network addresses with all zeros in the host portion, such as 10.50.0.0, can also produce a broadcast response. In the "smurf" attack, attackers are using ICMP echo request packets directed to IP broadcast addresses from remote locations to generate denial-of-service attacks. There are three parties in these attacks: the attacker, the intermediary, and the victim (note that the intermediary can also be a victim). The intermediary receives an ICMP echo request packet directed to the IP broadcast address of their network. If the intermediary does not filter ICMP traffic directed to IP broadcast addresses, many of the machines on the network will receive this ICMP echo request packet and send an ICMP echo reply packet back. When (potentially) all the machines on a network respond to this ICMP echo request, the result can be severe network congestion or outages. When the attackers create these packets, they do not use the IP address of their own machine as the source address. Instead, they create forged packets that contain the spoofed source address of the attacker's intended victim. The result is that when all the machines at the intermediary's site respond to the ICMP echo requests, they send replies to the victim's machine. The victim is sub- jected to network congestion that could potentially make the network unusable. Even though we have not labeled the intermediary as a "victim," the intermediary can be victimized by suffering the same types of problem that the "victim" does in these attacks. Attackers have developed automated tools that enable them to send these attacks to multiple intermediaries at the same time, causing all of the intermediaries to direct their responses to the same victim. Attackers have also developed tools to look for network routers that do not filter broadcast traffic and networks where multiple hosts respond. These networks can the subsequently be used as intermediaries in attacks. For a more detailed description of the "smurf" attack, please consult this document: "The Latest in Denial of Service Attacks: 'Smurfing': Description and Information to Minimize Effects" Author: Craig Huegen <[email protected]> URLs: http://www.quadrunner.com/~chuegen/smurf.txt and Smurfing: The Latest DoS Attack 1998 CERT ADVISORIES | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 2 [DISTRIBUTION STATEMENT A] Approved for public release and unlimited distribution. 1: CA-1998-01: Smurf IP Denial-of-Service Attacks II. Impact Both the intermediary and victim of this attack may suffer degraded network performance both on their internal networks or on their connection to the Internet. Performance may be degraded to the point that the network cannot be used. A significant enough stream of traffic can cause serious performance degradation for small and mid-level ISPs that supply service to the intermediaries or victims. Larger ISPs may see backbone degradation and peering saturation. III. Solution A. Solutions for the Intermediary 1. Disable IP-directed broadcasts at your router. One solution to prevent your site from being used as an intermediary in this attack is to disable IP-directed broadcasts at your router.

Load more