A Look Back at “Security Problems in the TCP/IP Protocol Suite”
Total Page：16
File Type：pdf, Size：1020Kb
A Look Back at “Security Problems in the TCP/IP Protocol Suite” Steven M. Bellovin AT&T Labs—Research [email protected] 1 Abstract 1 2 of the first three pieces of Ethernet ca- ble in all of AT&T, then a giant monopoly tele- About fifteen years ago, I wrote a paper on security prob- phone company. My lab had one cable, an- lems in the TCP/IP protocol suite, In particular, I focused on other lab had a second, and a “backbone” protocol-level issues, rather than implementation flaws. It linked the two labs. That backbone grew, as is instructive to look back at that paper, to see where my fo- other labs connected to it. Eventually, we cus and my predictions were accurate, where I was wrong, scrounged funds to set up links to other Bell and where dangers have yet to happen. This is a reprint of Labs locations; we called the resuling net- the original paper, with added commentary. work the “Bell Labs Internet” or the “R&D In- ternet”, the neologism “Intranet” not having been invented. Dedicated routers were rare then; we gen- 1. Introduction erally stuck a second Ethernet board into a VAX or a Sun and used it to do the routing. The paper “Security Problems in the This mean that the routing software (we used TCP/IP Protocol Suite” was originally pub- Berkeley's routed) was accessible to system lished in Computer Communication Re- administrators. And when things broke, we view, Vol. 19, No. 2, in April, 1989. It was a often discovered that it was a routing prob- protocol-level analysis; I intentionally did not lem: someone had misconfigured their ma- consider implementation or operational is- chine. Once, we found that someone had sues. I felt—and still feel—that that was the plugged a new workstation into the Murray right approach. Bugs come and go, and ev- Hill backbone, rather than into his depart- eryone's operational environment is different. ment's network; worse yet, the (proprietary) But it's very hard to fix protocol-level prob- address assignment software on his machine lems, especially if you want to maintain com- didn't see any (proprietary) address assign- patibility with the installed base. ment servers on that network, so it allocated This paper is a retrospective on my orig- .1—the gatewayy router—to itself. These two inal work. New commentary is shown in- situations worried me; it was clear that any- dented, in a sans serif font. The original thing that could happen by accident could be text is otherwise unchanged, except for pos- done deliberately, possibly with serious con- sible errors introduced when converting it sequences. from troff to LATEX. I've left the references in- Several other things focused my atten- tact, too, even if there are better versions tion on security even more. One was Robert today. The reference numbers and pag- Morris' discovery of sequence number ination are, of course, different; the sec- guessing attacks; these are discussed ex- tion numbers remain the same, except for tensively below. Another was the “Shadow a new “Conclusions” section. As a gen- Hawk” incident—a teenager broke into var- eral rule, the commentary follows the section ious AT&T computers [2]. He was detected it's discussing. when he tried to use uucp to grab pass- It helps to understand where this paper word files from various Research machines; came from. When I started work at Bell Labs a number of us had installed detectors for ex- Murray Hill in 1982, I assumed ownership of actly that sort of activity, and noticed the un- usual behavior. At that, we were lucky—most come de facto standards for many vendors, and not just for of the connectivity within AT&T was via the UNIX systems. proprietary Datakit network, which he didn't know how to exploit. One of the criticisms in [54]) was that I had lumped Berkeley-specific protocols to- By the time of the Internet worm of 1988, gether with standardized protocols described this paper was already in substantially its cur- in RFCs. It's quite clear from the preceed- rent form. The result was an analysis (to the ing paragraph that I understood the differ- best of my ability; I was relatively new to se- ence. However, the use of address-based curity at the time) of protocol-level problems authentication—a major flaw that I criti- in TCP/IP. cize throughout the paper—was peculiar to The original paper was criticized in [54]. Berkeley's software; I did not make that dis- Some of the criticisms were valid; some, in tinction clear. It is indeed a bad way to do au- my opinion, were not. At the time, I chose thentication, but it was not blessed by any not to publish a detailed rebuttal; I will not official standard. do so here. I have, where appropriate, noted where my analysis was especially incorrect. I did and do feel that my conclusions were sub- 2. TCP Sequence Number Prediction stantially correct. One of the more fascinating security holes was first de- The TCP/IP protocol suite [41, 21] which is very widely scribed by Morris [70]. Briefly, he used TCP sequence num- used today, was developed under the sponsorship of the De- ber prediction to construct a TCP packet sequence without partment of Defense. Despite that, there are a number of se- ever receiving any responses from the server. This allowed rious security flaws inherent in the protocols. Some of these him to spoof a trusted host on a local network. flaws exist because hosts rely on IP source address for au- The normal TCP connection establishment sequence in- thentication; the Berkeley “r-utilities” [22] are a notable ex- volves a 3-way handshake. The client selects and transmits ample. Others exist because network control mechanisms, an initial sequence number ISNC , the server acknowledges and in particular routing protocols, have minimal or non- it and sends its own sequence number ISNS, and the client existent authentication. acknowledges that. Following those three messages, data When describing such attacks, our basic assumption is transmission may take place. The exchange may be shown that the attacker has more or less complete control over schematically as follows: some machine connected to the Internet. This may be due ! to flaws in that machine's own protection mechanisms, or it C S : SYN(ISNC ) ! may be because that machine is a microcomputer, and inher- S C : SYN(ISNS); ACK(ISNC ) ently unprotected. Indeed, the attacker may even be a rogue C ! S : ACK(ISNS) system administrator. C ! S : data and/or S ! C : data 1.1. Exclusions That is, for a conversation to take place, C must first hear We are not concerned with flaws in particular implemen- ISNS, a more or less random number. tations of the protocols, such as those used by the Internet Suppose, though, that there was a way for an intruder X “worm” [95, 90, 38] Rather, we discuss generic problems to predict ISNS. In that case, it could send the following se- with the protocols themselves. As will be seen, careful im- quence to impersonate trusted host T : plementation techniques can alleviate or prevent some of these problems. Some of the protocols we discuss are de- X ! S : SYN(ISNX ); SRC = T rived from Berkeley's version of the UNIX system; others S ! T : SYN(ISNS); ACK(ISNX ) are generic Internet protocols. X ! S : ACK(ISNS); SRC = T We are also not concerned with classic network attacks, X ! S : ACK(ISNS); SRC = T; nasty − data such as physical eavesdropping, or altered or injected mes- sages. We discuss such problems only in so far as they are Even though the message S ! T does not go to X, X facilitated or possible because of protocol problems. was able to know its contents, and hence could send data. For the most part, there is no discussion here of If X were to perform this attack on a connection that al- vendor-specific protocols. We do discuss some prob- lows command execution (i.e., the Berkeley rsh server), ma- lems with Berkeley's protocols, since these have be- licious commands could be executed. How, then, to predict the random ISN? In Berkeley sys- by default on any 4.2BSD or 4.3BSD systems. tems, the initial sequence number variable is incremented There were still TOPS-20 systems on the net by a constant amount once per second, and by half that at that time; those systems had a vulnera- amount each time a connection is initiated. Thus, if one ini- ble netstat, a fact I refrained from mentioning tiates a legitimate connection and observes the ISNS used, for fear of pointing attackers at targets. Ac- 0 one can calculate, with a high degree of confidence, ISNS tual output is shown in Figure 1. used on the next connection attempt. There are several salient points here. The Morris points out that the reply message first, of course, which I stressed at the time, is that address-based authentication is very S ! T : SYN(ISNS); ACK(ISNX ) vulnerable to attack. I will return to this point does not in fact vanish down a black hole; rather, the real later. A second point is a threat I mention host T will receive it and attempt to reset the connection. later, but not in this context: if you know the This is not a serious obstacle. Morris found that by im- sequence numbers of an active session, you personating a server port on T , and by flooding that port can hijack it.