kernelthread.com

A Taste of Computer Security

© Amit Singh. All Rights Reserved. Written in June 2004


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)

DateHostsReported IncidentsReported Vulnerabilities
Dec 19694--
Sep 197118--
Dec 197331--
Oct 197449--
Jan 197663--
Mar 1977111--
Aug 1981213--
May 1982235--
Aug 1983562--
Oct 19841024--
Oct 19851,961--
Feb 19862308--
Dec 198728,174--
Oct 198856,0006-
Oct 1989159,000132-
Oct 1990313,000252-
Oct 1991617,000406-
Oct 19921,136,000773-
Oct 19932,056,0001,334-
Oct 19943,864,0002,340-
Jul 19958,200,0002,412171
Jul 199616,729,0002,573345
Jul 199726,053,0002,134311
Jul 199836,739,0003,734262
Jul 199956,218,0009,859417
Jul 200093,047,78521,7561,090
Jul 2001125,888,19752,6582,437
Jul 2002162,128,49382,0944,129
Jan 2003171,638,297137,5293,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.

Email

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.

<<< Security Uprooting Vehicles main Digital Life: Viruses >>>