These ridiculous attacks can be attributed almost feasible threats based on real features of the protocol Internet.
Almost viable threat in practice can not be done, or the likelihood of their success rezvychayno small. However, the hype raised by some not very competent foreign security experts Internet, misleading many users, creating a myth about these attacks, which are in fact almost no one is threatened.
1. IP-fragmentation as a way of penetration through the Firewall
As we know from the description of the protocol IP (RFC 791), the maximum IP-packet can reach 216-1 bytes. However, the size of the package (deytagram-we) passed directly through the channel of transmission, depending on the type of transmission medium. For example, in the Ethernet environment the maximum datagram size 1500 bytes, among ATM - 56 bytes. Therefore, to ensure that IP-packets can be transmitted over networks of any type in the IP protocol provides packet fragmentation.
That is to send one big package, he splits the corresponding number of smaller packets (their size is caused by a maximum size of packets to the transmission medium). This process is IP-packet decomposition into parts is called IP-fragmentation. The use of the Internet packet fragmentation makes it more flexible and invariant with respect to a variety of physical transmission medium. On Figure 4.12 shows the format of IP-packet version of IPv4.
We will not go into details, which means that each field in the IP-header (RFC 791), as in this case we are interested only in the field, and Fragment Offset Flags. In the Fragment Offset containing the value measured by eights bytes, indicating the displacement of the fragment relative to the datagram (namely that it is measured in the eight bytes, and drew the attention of Dr. FB Cohen in his article, Packet Fragmentation Attacks).
Thus, a unit in this field indicates the offset of 8 bytes from the beginning of the datagram. The Flags field shows whether the packet is fragmented or not.
So, what is the mechanism intended impact? As you know, one of the main functions of firewalls filtering is passing through their network traffic. In the case of filtering at the network level, limited access to certain services on the protected hosts. Type of service that the packet is determined by setting the destination port in the packet header TCP or UDP. Therefore, the firewall examines this parameter and verifies its compliance with those filtering rules that are installed on it.
In the case of compliance with the rules package passed on, otherwise - is filtered out.
The format of IP-packet version of IPv4.
4-bit Version 4-bit Header Length 8-bit Type of Service 16-bit Total
Length
16-bit Identification 3-bit Flags 13-bit Fragment Offset
8-bit Time to Live 8-bit Protocol 16-bit Header Checksum
32-bit Source Address
32-bit Destination Address
Options Padding
Data
Format TCP-packet.
16-bit Source Port Number 16-bit Destination Port Number
32-bit Sequence Number
32-bit Acknowledgement Number
4-bit Header Length 6-bit Reserved 6-bit Flags 16-bit Window Size
16-bit TCP Checksum 16-bit Urgent Pointer
Options Padding
Data
The format of UDP-packet.
16-bit Source Port Number 16-bit Destination Port Number
16-bit Length 16-bit Checksum
Data
In his article, Packet Fragmentation Attacks (published in All.net) Dr. F. B. Cohen proposed the following scenario of attack is to go through a fragmented packet through the firewall, bypassing the filtering rules.
Attacker breaks the packet into two fragments, the first of which contains a bogus TCP-or UDP-header with a destination port number, which is not filtered at the firewall rules (for example, port 25 - SMTP-mail server), while the second has a bias (equal to 1) in the Fragment Offset, which overlaps the first packet and writes in the "destination port" port of the true value of the service that you access through the firewall is disabled. In this case, the filter rules on the firewall to miss this IP-packet, so the firewall is not engaged in assembling the fragmented IP-packets.
With this article, Dr. Cohen'a occurred over time rather curious changes. The article, which the authors found on the WWW-server all.net in May 1996 for the implementation of the attack suggested recorded in the field of Fragment Offset value
Indeed, the assembly of fragmented IP-packages first deals with the operating system is the final destination of package and the assembly, as a rule, is not tested is not whether the packet fragments are superimposed on each other. Network operating system collects fragmented packets and transmits it to the appropriate service, based on the value in the port of destination. At first glance, the attack took place: a fragmented packet sent by one service, passed through the firewall and the assembly of fragments transferred to another service, access to which was banned by the firewall filtering rules. However, Dr. F. B. Cohen does not take into account the important fact that the value of the displacement field according to the specifications indicated in the eight bytes, and even if you set this value to one and assume that the network operating system does not check for the imposition of fragments, after assembling the fragments will be sanctioned only after the first eight bytes of TCP - or UDP-header, in which, as can be seen from Fig. 4.12, and contains fields destination ports.
Some time after publication of an article by Dr. Cohen, apparently, found the above error and revised the attack scenario one change:
unit in the field of Fragment Offset now was it replaced with a 0!
Let us analyze how this change will make possible the implementation of this attack.
Indeed, in this case, the attack can be successful, since the field of Flags (an indicator of fragmentation) in the second packet the attacker can fill in the necessary manner to him, but because it is based on the value of this field is the network operating system must make a decision to start assembling the fragments.
However, analysis of the kernel source operating systems Linux and FreeBSD has shown that the IP-packet will be accepted by those operating as a movie only if the value in the Fragment Offset is not equal to 0! Nevertheless, since the algorithm assembly of fragments, as described in RFC 791, does not require verification of the value of this field, it is possible that some network operating systems do not produce it (unlikely!) And, therefore, the attack can be successful.
It seems to us, the idea of blending the fragments is a rather curious. Another thing is that its application for the penetration of the attacking packets through Firewall in the current IPv4 standard is unlikely.
2. Exceeding the maximum size IP-packet or Ping Death
In the maximum IP-packet (65535 bytes) includes the length of IP-header and the length of data field in the IP-packet.
Since the IP-header has a minimum size of 20 bytes (maximum of 60), respectively, the amount transferred in a single IP-packet data can not exceed 65535 - 20 = 65,515 bytes. And what if it exceeded the maximum size of IP-packet?
Test their programs on the minimum and, most importantly, to the maximum value, ie the critical limits - the standard for any programming course.
Such tests can identify these nasty bugs, as all kinds of overflow (buffer, stack, variable, etc.).
We return to the IP. In principle, nothing prevents an attacker to create a set of fragments, which after assembly will exceed the maximum possible size of the IP-packet. Actually, in this phrase and the main idea of this attack.
So, 18 December 1996 on an information server, CERT was reported that most network operating systems, supporting the protocols TCP / IP, have the following vulnerabilities:
transfer them IP-packet length exceeding the maximum allowable value of these operating systems overflowed buffer, or variable, and the system hangs or reboots, etc. - a denial of service! Also was given the following list of potentially dangerous platforms:
Berkeley Software Design, Inc. (BSDI); Computer Associates, Intl.
(Products for NCR); Cray Research; Digital Equipment Corporation; FreeBSD,
Inc.; Hewlett-Packard Company; IBM Corporation; Linux Systems; NEC
Corporation; Open Software Foundation (OSF); The Santa Cruz Operation,
Inc. (SCO); Sun Microsystems, Inc.
Seeing the message of such an attack and, more importantly, the list of operating systems on different platforms, we are surprised with the greatest long reread it, and then took over the experiments.
Our deepest astonishment was the fact that such base buffer overflow in the kernel IP module for almost 20 years of active operation of the IP protocol for various operating systems, developers of today's systems, so even in such large numbers are still not
noticed!
Therefore, we afford not to believe such a reputable organization such as CERT.
But before you start experimenting, it was decided to look at this in the CERT link on the WWW-server, where experts conducted similar studies on different operating systems. There's actually like to CERT, the attack was called Ping Death. On this WWW-server proposing to implement such an attack as follows: on a workstation running Windows '95 or Windows NT, run the following command:
ping-l 65527 victim.destination.IP. address (so - Ping Death).
Since the typical size of the IP-header is 20 bytes in size
ICMP-header - 8 bytes, the ICMP-like package will exceed
the maximum possible size of the IP-packet of 20 bytes (65 527 + 20 8 - 65535 = 20).
Thus, these experts declared that the regular ping command allegedly can not operate almost any network operating system. In conclusion on this server contains the following table testing different operating systems on which this remote attack allegedly produced the desired effect. Further, the authors would like to show you this table with a substantial reduction.
Do not you think, this table of operating systems that have this vulnerability, makes an impression!
So we started testing, and, frankly, absolutely not surprised when none of the investigated operating systems, or IRIX, or AIX, or VMS, or SunOs, or FreeBSD, or Linux, or Windows NT 4.0, or even Windows '95 and Windows for WorkGroups 3.11, absolutely no way to respond to such an invalid request and continued to function normally! Were then pursued a search for the OS, which would really be put out of action this attack.
It was with Windows 3.11 WinQVT - this OS is really hung.
Affected operating systems
Operating system Version Symptoms
Solaris (x86) 2.4, 2.5, 2.5.1
Reboot
Minix 1.7.4, v2.0 and probably others Crash
HP3000 MPE / iX 4.0, 5.0, 5.5
System abort
Convex SPP-UX All version Crash
Apple Mac MacOs 7.x.x Crash
Windows 3.11 with Trumpet Winsock?
Mixed reports
Novell NetWare 3.x Mixed results
Windows '95 All of 'em Crrrash
AIX
3 and 4 Operating system dump.
Linux? 2.0.23
Spontaneous reboot or kernel panic
DEC Unix/OSF1 2.0 and above Kernel Panic
Open VMS for AXP various Mixed reports
Open VMS for VAX v6.2, UCX v4.0 and others Reboot
HP-UX
9.0 to 10.20 Crash, Reboot, Hang ...
Windows NT 3.5.1
Mixed results
Irix 5.3
Panic
Windows NT 4.0
Crash
SCO Openserver 4.2, 5.0.x Vulnerable
DEC TOPS-20, TOPS-10
All Errors
Digital Firewall?
Vulnerable
AltaVista Firewall for UNIX?
Vulnerable
At the request sent by this so-called experts who so trust the CERT and CIAC, where we were asked to clarify the situation arose, as well as information from Table 4.13, a reply was received, it stated that the success of this attack depends on many factors, namely: hardware and software installed on your computer and, most importantly,
phases of the moon.
Agree, bullshit! For completeness, we would like to continue to give a description exploit'a created for Windows NT 4.0, whose task, using ping, hang your own computer.
The first step is proposed to launch Web Browser (?). The second step is required to run taskmgr (Task Manager)
(??). The comments to this step saying that since the Ping Death works better (not enough shaman's tambourine!). And finally, as required
18 ping-run processes (???) (no more and no less, may be better to just 100 - what a trifle!). If you think that your OS then immediately hang, you're wrong! In comments to exploit'u to effect proposed to wait about 10 minutes, with the philosophical observation that the wait can last a few more (I wonder how much longer - an hour, month, year?) Or slightly less.
As a result, we can conclude that the hype raised in the CERT and CIAC about this attack is baseless, and anything else we probably do, but called the attack the next programmer bikes and classify it to the category impracticable.
|
