A Taste of Computer Security
The Net Growth In Insecurity
The proliferation of networking has aided computer insecurity in many ways: by presenting additional vulnerable resources (such as the network itself, and millions of computers) and by connecting many more people together (more disinformation, more social engineering, more electronic mail, more communication scenarios in general). Certainly, these are good things, with some caveats and potential dangers. We could not be expected to simply not network, so we have to "deal with it".
Some Growth!
Work began on the world's first packet switching network at the National Physics Laboratory in the United Kingdom in the 1960s. This was soon followed by the ARPANET, and many others thereafter. By the end of 1969, the ARPANET had 4 sites, with Interface Message Processors (IMPs) installed at UCLA, SRI (Menlo Park), UCSB, and the University of Utah. The IMPs were built around Honeywell 516 computers, and were linked using dedicated 55 Kbps phone lines. Consider the growth of the Internet over the years, along with a sample quantification of the growth in insecurity:
Growth of the Internet (and Insecurity) |
|||
|---|---|---|---|
| Date | Hosts | Reported Incidents | Reported Vulnerabilities |
| Dec 1969 | 4 | - | - |
| Sep 1971 | 18 | - | - |
| Dec 1973 | 31 | - | - |
| Oct 1974 | 49 | - | - |
| Jan 1976 | 63 | - | - |
| Mar 1977 | 111 | - | - |
| Aug 1981 | 213 | - | - |
| May 1982 | 235 | - | - |
| Aug 1983 | 562 | - | - |
| Oct 1984 | 1024 | - | - |
| Oct 1985 | 1,961 | - | - |
| Feb 1986 | 2308 | - | - |
| Dec 1987 | 28,174 | - | - |
| Oct 1988 | 56,000 | 6 | - |
| Oct 1989 | 159,000 | 132 | - |
| Oct 1990 | 313,000 | 252 | - |
| Oct 1991 | 617,000 | 406 | - |
| Oct 1992 | 1,136,000 | 773 | - |
| Oct 1993 | 2,056,000 | 1,334 | - |
| Oct 1994 | 3,864,000 | 2,340 | - |
| Jul 1995 | 8,200,000 | 2,412 | 171 |
| Jul 1996 | 16,729,000 | 2,573 | 345 |
| Jul 1997 | 26,053,000 | 2,134 | 311 |
| Jul 1998 | 36,739,000 | 3,734 | 262 |
| Jul 1999 | 56,218,000 | 9,859 | 417 |
| Jul 2000 | 93,047,785 | 21,756 | 1,090 |
| Jul 2001 | 125,888,197 | 52,658 | 2,437 |
| Jul 2002 | 162,128,493 | 82,094 | 4,129 |
| Jan 2003 | 171,638,297 | 137,529 | 3,784 |
Data source for number of hosts: Internet Systems Consortium.
Data source for security numbers: CERT.
Security numbers are for the entire year, and only include those that were reported to CERT.
Computer networks play a role in essentially every attack today, and numerous attacks focus on the networks themselves, rather than simply using them as a communication channel. Networks could be attacked passively (somebody monitors, or "sniffs" a network and gleans sensitive information, without modifying any data), or actively (somebody reroutes certain messages, introduces additional messages, or modifies existing messages). Using one or more of these approaches and techniques, existing network connections could be hijacked or terminated; a third party could capture and replay transactions between two parties; a third party could be the proverbial man-in-the-middle in between two parties, and pretend to be one party to the other.
Developments in cryptography, if implemented and used properly, can and do offset many of these risks.
The ability to receive email is one of the greatest joys of computing. Most computer users I know used to get depressed if they had not received any email within the last hour. I suspect the scourge of spam might have changed that feeling.
This modern day's preferred mode of communication is an ideal vehicle for rogue code. However, email "bombs" (pieces of code that can trigger harmful operations when an email is "opened") go back quite far in history. In the olden days (when there were no Word document attachments), a bomb sender could have embedded escape sequences for a terminal in the mail text. Potentially harmful operations could be performed if the recipient viewed the text on a terminal honoring the sequences. For example, if a terminal allowed escape sequences to insert characters in its input buffer, an email could trigger execution of commands on the receiver's machine.
Today's viewing devices are not free from escape sequences. The popular xterm on various Unix systems, and Terminal.app on Mac OS X, both honor several potentially irritating (if not critically harmful) escape sequences. A partial list of such sequences is given below. These may not "work" (negatively) on all xterm implementations. You could "try" these by creating a file, say, using vi, typing the sequence, saving the file, and then cat'ing it. Note that the ^[ is the escape character, entered in vi by typing ctrl-v.
^[(0 |
garbles xterms that use the US ASCII character set |
^[(B |
restores US ASCII character set |
^[[?5h |
sets reverse video |
^[[?9h |
sets sending of MIT mouse row/column on button press: will mess up text selection |
^[]P10;colorspec^G |
sets foreground color to that specified by colorspec |
^[]P11;colorspec^G |
sets background color to that specified by colorspec |
^[P0;0 |
locks keyboard |
Greener pastures for mail bombing appeared as mail programs provided versatile execution environments in their attempts to be feature-rich, convenient, and user-friendly. It is a tough wire to walk. While such features are meant to improve work-flow and are desirable, as programs become complex, policies must be devised to specify resources that embedded programs are allowed to access. Users are not very patient in general, and often they would simply run whatever wants to run!
It is usually rather difficult to combine security and ease-of-use.