informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/FIDONEWS/fido0526.nws

1568 lines
69 KiB
Plaintext
Raw 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.

Volume 5, Number 26 27 June 1988
+---------------------------------------------------------------+
| _ |
| / \ |
| /|oo \ |
| - FidoNews - (_| /_) |
| _`@/_ \ _ |
| International | | \ \\ |
| FidoNet Association | (*) | \ )) |
| Newsletter ______ |__U__| / \// |
| / FIDO \ _//|| _\ / |
| (________) (_/(_|(____/ |
| (jm) |
+---------------------------------------------------------------+
Editor in Chief Dale Lovell
Editor Emeritus: Thom Henderson
Chief Procrastinator Emeritus: Tom Jennings
Contributing Editors: Al Arango
FidoNews is published weekly by the International FidoNet
Association as its official newsletter. You are encouraged to
submit articles for publication in FidoNews. Article submission
standards are contained in the file ARTSPEC.DOC, available from
node 1:1/1.
Copyright 1988 by the International FidoNet Association. All
rights reserved. Duplication and/or distribution permitted for
noncommercial purposes only. For use in other circumstances,
please contact IFNA at (314) 576-4067. IFNA may also be contacted
at PO Box 41143, St. Louis, MO 63141.
Fido and FidoNet are registered trademarks of Tom Jennings of
Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and
are used with permission.
The contents of the articles contained here are not our
responsibility, nor do we necessarily agree with them.
Everything here is subject to debate. We publish EVERYTHING
received.
Table of Contents
1. ARTICLES ................................................. 1
A By Law proposal ........................................ 1
EchoMail, Blessing or Bane? .............................. 7
Killing Viruses .......................................... 9
2. NOTICES .................................................. 23
The Interrupt Stack ...................................... 23
Latest Software Versions ................................. 23
FidoCon '88 Registration Form ............................ 25
FidoNews 5-26 Page 1 27 Jun 1988
=================================================================
ARTICLES
=================================================================
Neal Curtin
1:343/1
Change to the By Laws
The following is submitted as a set of proposed amendments to
the BY-LAWS of the International FidoNet Association. They are
proposed to the Chairman of the Bylaws Committee, and to the
Board of Directors of the said International FidoNet Association.
Proposal 1.
Current Wording.
Preamble:
IFNA NODELIST: The list, prepared by the IFNA Vice President
- Technical Coordinator, of active nodes in the IFNA NETWORK.
IFNA NETWORK: The current set of systems which have been
certified as FidoNet compatible and conform to policies
established by the Board of Directors.
PUBLIC ACCESS: A system that has a telephone number published
in the IFNA Nodelist, and in addition provides services to
the public.
Suggested Wording:
Nodelist: The list, prepared by the various Zone
Coordinators, of active nodes within their zone, and on file
with the International Coordinator.
Network: The current set of systems which have been certified
as Fidonet compatible, and conform to the policies
established by their respective net, region, and zone.
PUBLIC ACCESS: A system that has a telephone number published
in the Nodelist, and in addition provides services to the
public.
Added wording:
International Coordinator: The individual elected by the
various zones and regional coordinators to arbitrate and rule
on inter-zonal disputes. In addition, the International
Coordinator is the person responsible for coordination
FidoNews 5-26 Page 2 27 Jun 1988
between the zones and is responsible for establishing new
zones as the case may arise.
Rationale:
These changes are proposed to eliminate the implication, real
or perceived, that the association owns, controls, or
manipulates the FidoNet network.
Proposal #2
Proposed changes to section 1
Current wording:
1(a) Regular Member. To be eligible, an applicant: must be
the system operator in good standing of a PUBLIC ACCESS node;
must have paid any dues required; is entitled to one vote.
1(b) Associate Member. Any person who is not eligible to be a
Regular Member, but who is interested in electronic
communications, is eligible to be an Associate Member by
paying required dues. Associate Members have all of the
rights of a Regular Member except the right to vote.
1(c) Commercial Member. Any entity using the IFNA NETWORK for
the conduct of any business is eligible to be a Commercial
Member by paying required dues. Any Commercial Member also
satisfying the requirements to be a Regular Member shall be
entitled to vote.
Proposed wording:
1(a) Regular Member. To be eligible, an applicant: must be
the system operator in good standing of a PUBLIC ACCESS
node; must be listed in a nodelist; must have paid any dues
required; is entitled to one vote.
1(b) Associate Member. Any person who is listed in a
nodelist. or who is interested in electronic communications,
is eligible to be an Associate Member by making application
for membership. Associate Members have all of the rights of a
Regular Member except the right to vote.
1(c) Commercial Member. Any entity using the IFNA NETWORK for
the conduct of any business is eligible to be a Commercial
Member by paying required dues. Any Commercial Member also
satisfying the requirements to be a Regular Member shall be
entitled to vote.
Rational:
These changes are designed to broaden the scope of eligibility,
and include all sysops who are listed in a FidoNet Compatible
nodelist.
FidoNews 5-26 Page 3 27 Jun 1988
Proposal 3.
Proposed changes to Section 2 and 3.
Current wording
2. Applications for membership shall be submitted to the
Secretary. In the case of any applicant whose character,
reputation or conduct might make him an undesirable member,
the Secretary shall refer the application to the Executive
Committee for review; in all other cases, the Secretary shall
have the authority to grant membership.
3. The Secretary shall notify members of the expiration of
their membership not less than thirty days prior to
expiration. In determining membership status, memberships
renewed within thirty days of expiration shall be regarded as
continuous.
Proposed changes
2. Applications for membership shall be submitted to the
Membership Committee. In the case of any applicant whose
character, reputation or conduct might make him an
undesirable member, the membership Committee shall refer the
application to the Executive Committee for review; in all
other cases, the Membership Committee shall have the
authority to grant membership.
3. The Membership Committee shall notify members of the
expiration of their membership not less than thirty days
prior to expiration. In determining membership status,
memberships renewed within thirty days of expiration shall be
regarded as continuous.
Rational:
The secretary does not now, nor has he ever been, involved in
membership. The application goes to the Treasurer, who notifies
the Membership Services Committee, who sends out the membership
card.
Proposal #4
Proposed changes to section 25
Current wording:
25. The following voting divisions are established:
Division 2 Europe, Africa
Division 10 CA NV
Division 11 IL IN KY MI OH WI - USA and ON PQ PEI NS NB NF
-Canada
Division 12 HI Asia, Australia, Antarctica
Division 13 DE DC MD NJ NY PA VA
Division 14 IA KS MN MO NB ND SD
Division 15 AZ CO NM UT WY
FidoNews 5-26 Page 4 27 Jun 1988
Division 16 CT ME MA NH RI VT
Division 17 AK ID MT OR WA - USA and BC ALB SSK -Canada
Division 18 AL FL GA MS NC SC TN
Division 19 AR LA OK TX, South America,
Mexico, Central America
Proposed change:
25. The following voting divisions are established:
Division 2 Europe, Africa
Division 3 Australia, Southern Pacific
Division 4 AlterNet
Division 5 GoodEggNet
Division 6 Canada
Division 7 Central and South America
Division 8 IL IN KY MI OH WI
Division 9 DE DC MD NJ NY PA VA
Division 10 IA KS MN MO NB ND SD
Division 11 AZ CO NM UT WY
Division 12 CT ME MA NH RI VT
Division 13 AK HI ID MT OR WA
Division 14 AL FL GA MS NC SC TN
Division 15 AR LA OK TX
These divisions may be changed by a two thirds vote of the
Board of Directors, and should include new zones and new
Nodelists of over 100 systems.
Rational:
The current system does not give enough representation on the
board to overseas areas and tends to be inflexible.
Proposal #5
Proposed changes to section 28
Current Wording:
28. The Secretary shall: record the proceedings of all
meetings of the Board and of the Executive Committee;
promptly furnish copies of the minutes of these meetings to
all officers and members of the Board;publish such minutes in
FidoNews; be responsible for the maintenance of the corporate
status of IFNA and the filing of all reports and certificates
which may be required of IFNA under the corporation laws of
the State of Missouri; be the archivist of IFNA; maintain the
corporate membership and voting records of IFNA; performs
other duties as described in applicable Bylaws. To the extent
that may from time to time be required by law, he shall act
as agent for the service of process but only while present in
the State of Missouri and he is not authorized to accept
service of process elsewhere.
Proposed Change:
28. The Secretary shall: record the proceedings of all
FidoNews 5-26 Page 5 27 Jun 1988
meetings of the Board and of the Executive Committee;
promptly furnish copies of the minutes of these meetings to
all officers and members of the Board; publish such minutes
in FidoNews; be responsible for the maintenance of the
corporate status of IFNA and the filing of all reports and
certificates which may be required of IFNA under the
corporation laws of the State of Missouri; be the archivist
of IFNA; maintain voting records of IFNA; performs other
duties as described in applicable Bylaws. To the extent that
may from time to time be required by law, he shall act as
agent for the service of process but only while present in
the State of Missouri and he is not authorized to accept
service of process elsewhere.
Rational:
Eliminates the requirement that the secretary maintain the
membership roster.
Proposal #6
Proposed changes to section 30
Current wording:
30. The Vice President - Technical Coordinator shall: be
responsible for maintenance and distribution of the master
NODELIST; creation and distribution of the weekly update file
for the master NODELIST; ensuring the smooth operation of
the IFNA NETWORK as prescribed by the Board of Directors;
serve as a member of the Technical Standards Committee.
Proposed change:
30. The Vice President - Technical Coordinator shall: serve
as a member of the Technical Standards Committee, and be
responsible for the development and publication of standards
for system software so as to ensure compatibility between the
various nodes. The VP-TC will assist the various Coordinators
in technical matters.
Rational:
This change to eliminate the implied or perceived implication
of that IFNA desires or wants to control the nodelist. The
reference to the IC is dropped and would no longer be a IFNA
position.
Proposal #7
Proposed changes to section 40
Current wording:
40. There shall be an official publication maintained by
IFNA, in the form of a weekly journal, the name of which
shall be FidoNews. A copy of this journal shall be available
each week to every member of IFNA in good standing. The
General management of this journal shall be in the hands
of the President. The policy of the journal shall be
FidoNews 5-26 Page 6 27 Jun 1988
determined by the Board of Directors.
Proposed change:
40. There shall be an official publication maintained by
IFNA, in the form of a weekly journal, the name of which
shall be FidoNews. A copy of this journal shall be available
each week to all listed nodes. The general management of this
journal shall be in the hands of the President. The policy of
the journal shall be to publish all submitted articles of
interest to the FidoNet community, within the bounds of
legality and good taste.
Rational:
This change is to eliminate the reference that the journal is
only for IFNA members, and to give some firm direction to the
editorial staff.
Respectively submitted by Neal Curtin, Network Coordinator, Net
1:343.
-----------------------------------------------------------------
FidoNews 5-26 Page 7 27 Jun 1988
Bob Morris
FN 1:141/333, 1:141/386
AN 7/1, 7/13, 7:46/1, 7:46/2 and 7:46/3
Echomail, the thing which allows our users (you remember them)
to communicate with the rest of the world on things that are
bothering them, technical issues, as well as speciality areas.
EchoMail has become something of a monster, what we all
use to help support and have become "HOOKED" on is now being
used as the carrot which the EchoMail Backbone, REC's, NEC's
and what ever use to limit our links to other systems across
the world.
EchoMail was designed by Jeff Rush and it was a GREAT idea of
getting the same message out to a lot of people at the same
time. But in today's environment, EchoMail has established
a new power point to control what we all do for our users,
including what type modems are utilized, the hours that
echomail can be picked up, the systems which can called to
pick up these areas and last, but not least, who we
can align ourselves with when it comes time to use software
to process this whole mess.
In this Sysop's mind, it has become a monster which in the last
20 months has accomplished the following items without the
least amount of trouble.
1. The splitting of the Network (FidoNet as we knew it in
January of 1987) into different Networks.
2. The demise of good working relationships.
3. The phrase "FLAME ON".
4. The inability of people to "read" humor or anything else
within the written word. This has lead to many people not
being able to understand the context of many of the
messages that we all read on a daily basis.
5. The demise of IFNA as well as causing it to become
unable to accomplish anything based upon the problems
associated with Electronic Mail especially that of Echo-
Mail.
6. The establishment of the *EC positions, which when they
started, were needed, but now they duplicate the *C
positions and are now wielding more power and control
than their contemporaries within the FidoNet Administrator
Positions.
7. The disenchantment of Sysops as a whole about the world
of BBSing, causing them to DROP OUT entirely, or at the
least the seeking of Alternatives to the HATEMail which
now proliferates the AREAS.BBS today.
FidoNews 5-26 Page 8 27 Jun 1988
8. The establishment of EchoMail areas which do nothing but
allow people who moderate EchoMail areas a place to
discuss what is happening within the world of echomail
and to discuss how to furthur control who can get
direct access to an EchoMail area.
If you read this article as "Sour Grapes" (one less than a
FLAME) then that is what I intended it to do. If you read it
as an indictment of the EchoMail process as it exists today,
then, again, it is something that I intended to do. If you
read this article and feel as though I am saying that the need
for an enforcement procedure is bad, then I have again
accomplished what I set out to do. If you read this and find
that someone is imposing a set of rules upon the manner in
which you and your USER must share ideas, thoughts and
other information which is posted in the EchoMail Areas, then
again, I have accomplished what I set out to do.
I am NOT saying that EchoMail Coordination is bad, I am saying
that the people who Coordinate the running of the EchoMail
distribution are imposing a set of rules and regulations which
have not been accepted by the Sysop Community as a whole. I am
also stating that pickups outside of a region, as long as they
are closed loops, stand little if any chance of generating
duplicates within any given region. Links outside of a given
Region provide for a backup link in case of disaster or full
disk drives.
Within AlterNet, there is a stated Policy concerning EchoMail,
that Policy is to "Be Polite, and if you cannot add anything to
a conference which is Positive, then do not use the conference"
this Policy is followed by the vast majority of the AlterNet
Community, unfortunately, it does not have to apply to the
FidoNet Community.
EchoMail, from my view point, has broadened my scope as far as
what is happening within the Networks, but it has soured me as
far as my view point of other Sysops and also the way that they
look at me. It is a two way street, no one wins, and only AT&T,
SPRINT, MCI, GTE and PCP have won as they get all the neat
profits from our expenses.
A few last points, do we really need all 225 conferences? Do
we really need all of this to make sure that our users get a
couple of EchoMail areas? Or are we doing this just so that
our Blood Pressure gets up at least once a day?
Bob Morris
FN 141/333, 141/386
AN 7/1, 7/13, 46/1, 46/2, 46/3
-----------------------------------------------------------------
FidoNews 5-26 Page 9 27 Jun 1988
Lee Kemp, Communet 1:221/162.14
7 June 1988
K I L L I N G V I R U S E S
1. INTRODUCTION
Numerous utilities have been released for detecting "virus"
programs before they damage hard disks or get passed on.
Unfortunately this won't work. Existing viruses will continue to
spread from diskettes already infected, and will re-infect
computers that have been through it before. New more virulent
strains will be developed to overcome each new detection utility
released (perhaps by infecting the utilities themselves!)
I believe I've figured out a method that WILL work. The World
Health Organization managed to stamp out smallpox through a
coordinated international campaign and I believe we can do the
same for ALL computer viruses - but it will require a coordinated
campaign.
This article lays out the basic idea and asks for help. Help
through any constructive criticisms or alternative proposals,
help through negative, destructive "flames" if the idea is all
wrong, so I'll stop wasting time on it, and help from any
software developers willing to "send code".
However I am not interested in corresponding about whether
destructive Trojan viruses actually exist and whether they will
become a serious problem. Its far too late to be discussing THAT.
First, some reasons why its worth working on the solution I
propose.
1.1 There is NO way to detect viruses
None of the methods currently used have the SLIGHTEST chance of
detecting a reasonably well designed Trojan, let alone a genuine
virus. Tests that are just done when software is first received,
and just consist of running a utility over it once, or installing
a TSR monitor, are ALREADY completely useless.
Any jerk can write a Trojan that won't do anything suspicious
while it's being tested, and the test utilities themselves are
likely to be a target for more sophisticated viruses.
Ideas like continually monitoring disk writes are ok for the
first generation of Trojans but simply won't work with the next
generation. Actually they will become positively dangerous. A
virus could simply recognize the particular TSR that's monitoring
it, grab the interrupts back, and send reassuring messages to the
SysOp, while it doesn't even bother to WAIT before starting to
infect other software! A false sense of security is MUCH worse
than the knowledge that anything you make available for download
FidoNews 5-26 Page 10 27 Jun 1988
COULD be a virus.
Source code for IBM ROM BIOS is available in the Technical
Reference manuals for anyone who wants to write Trojans that
access disk controllers directly. Also there are ways to do
apparently "legitimate" disk writes that do no immediate damage
but can trigger an infection later.
Much more sophisticated approaches to delayed action are
available than using the DOS date function.
Checksums of operating system files and their dates and times are
easily bypassed.
Proper testing requires at least the sort of insulation from the
hardware and operating system that is provided by a 386 running
in virtual 8086 mode. Worse, there are even ways around THAT,
which I won't go into here.
Anyone familiar with the secure design of operating systems
understands that there is NO way an application program can be
prevented from doing whatever it damn well pleases when the
underlying CPU hardware doesn't run in a protected mode. OS/2 and
Unix run in a protected mode but MSDOS normally doesn't, and
CAN'T on XTs and ATs.
Even protected mode isn't enough, given the practical realities
of normal security precautions. Controlled experiments with Unix
viruses have achieved root privileges in less than an hour, with
an average of 30 minutes. (F. Cohen, "Computer Viruses: Theory
and Experiments", University of Southern California, August 1984,
cited in Wood and Kochan, "Unix System Security", Hayden Book
Company, 1985)
The SERIOUS work in computer security is being done on how to
protect a system when you have complete source code for
everything run on it - and THAT is damn difficult. ADA and Pascal
are languages intended to allow you to figure out what the source
code actually does, but C is the language of micro applications
and its designed for efficiency, not correctness proofs. Take a
look at the fast table driven CRC routines used in most FidoNet
mailers these days. How many C programmers have the faintest idea
what they ACTUALLY do?
Serious computer security work also deals with problems like
"compiler viruses", that install themselves in any software
compiled, including new versions of the compiler. Who REALLY
knows what's in most microcomputer object code - not even the
authors!
There is NO serious work being done on protection from real mode
applications running on 80x86 machines. Because it SIMPLY CAN'T
BE DONE.
Now sit back and think about the implications of that for 3000
FidoNet nodes around the world continually exchanging software
FidoNews 5-26 Page 11 27 Jun 1988
with each other and their users! This network can spread a deadly
virus around the world within DAYS (if not hours).
1.2 We don't have time for testing
ANY partially useful testing system for the next generation of
viruses would require tests EVERY time a copy of ANY software is
made available for distribution, and fairly elaborate procedures
to ensure the testing is done on an uninfected machine with
uninfected test utilities.
Even factory fresh diskettes from major software houses have
ALREADY been infected, so what's to stop the latest upgrade of
some commercial package infecting a machine that's been carefully
kept "clean"? Even Harvard couldn't persuade Lotus to let them
retain their policy of ONLY running software for which they had
compiled the source code themselves.
BBS SysOps just don't have the time to properly test files they
make available for download, even to detect fairly crude Trojans.
Neither do end users. Even PARTIALLY useful serious tests simply
won't be widely used until AFTER there has been some MAJOR damage
done. The time wasted on serious testing will then be almost as
damaging as actual loss of data.
1.3 We can't afford to just keep quiet and hope
The first generation of diskette based viruses has now become of
sufficient public interest for full page articles in daily
newspapers as well as computer magazines. It is therefore CERTAIN
that some warped people will take up the challenge to design the
next generation. It is also very likely to happen SOON.
In case anybody thinks that mentioning all this could give people
ideas, I should point out that the technical points made above
will be obvious to anybody TRYING to figure out how to get past
present detection utilities. People who have ALREADY shown much
more sophistication with Unix viruses will now be focussing their
attention on personal computer diskette based viruses as a result
of the newspaper publicity if nothing else.
I am deliberately refraining from mentioning some approaches that
are obvious to me, but that may not be thought of immediately by
just ANYBODY contemplating a virus program, in case that can give
an extra breathing space. But I KNOW that there ARE ways to
unleash delayed action virus programs that CANNOT be detected by
ANY feasible method. I don't think it will be long before these
more sophisticated approaches become general public knowledge
too.
A basic issue is that viruses involve quite different problems
from simple Trojans. They can spread WITHOUT doing overt damage.
I am writing a separate technical paper on all this, which shows
FidoNews 5-26 Page 12 27 Jun 1988
that FidoNet itself is in special "clear and present danger" with
more than the usual problems faced by all BBSes. Anyone wanting a
copy should NetMail me direct, explaining why they have a
legitimate "need to know" and with an undertaking not to pass on
the information. This paper is not available for file request but
will be crashed direct to responsible software developers
interested in working on solutions.
I sent a message about these problems to the International
Coordinator of FidoNet nearly three months ago. He replied to
other matters in the same message in a manner indicating that he
had not understand anything I said to him, and he did not reply
at all on this issue. Judging from that and other indications, I
do not believe that the authorities within FidoNet who ought to
take the initiative to do something about this situation are
likely to do so. (For that matter my experience with the IC is
that he also thinks he can avoid other serious problems by
sticking his head in the sand). I see no choice but to now pass
on the information direct to interested and responsible software
developers.
There's no point refraining from public discussion, when full
page articles about computer viruses are appearing in daily
newspapers, and when people responsible for administration of
FidoNet won't listen AT ALL.
Ok, now as well as being necessary to look at new solutions, it's
also URGENT to do so.
2. WHY ITS URGENT
"Computer AIDS" is likely to have as devastating an effect on
BBSes and FidoNet as the original AIDS has already had on gays,
and is now having on the wider community. Unless something is
done NOW, we are CERTAIN to eventually be hit by some really
deadly virus that has been spread to literally thousands of
public access BBS systems through FidoNet and will then, months
later, cause literally millions of dollars worth of damage to
data on literally tens of thousands of users hard disks. The
problem is THAT serious.
Apart from jerks, there are economic interests that actually
stand to GAIN from destructive viruses, because public domain
software, and the "sharing" of other software that often occurs
among people who use public domain software, directly competes
with their own commercial interests.
As Nicholas Rothwell points out in his article on "Computer
AIDS":
But what if one does not want to create trouble, but
rather to destroy trust? For that is what is at stake.
Without open communication, without "public domain"
software, without free exchange of academic and
technical software, the personal computer revolution is
FidoNews 5-26 Page 13 27 Jun 1988
hamstrung.
There are plenty of technically competent people in FidoNet who
are out to destroy trust and are opposed to open communication.
I'll be going into that in a later article.
Last month a report for the European Commission issued a formal
blunt warning that computer networks across the member nations of
the European Community were not safe:
Unless action is taken to improve levels of computer
and network security, the consequences for individual
enterprises could be severe, even catastrophic.
For FidoNet the consequences would be catastrophic, not just
"severe". It is one of the world's largest computer networks, but
with virtually NO security and LOTS of jerks.
We are supposed to be a network dedicated to the free exchange of
information. If instead we become known as a network that has
done millions of dollars worth of PREDICTABLE damage that COULD
have been avoided by SIMPLE countermeasures, then both individual
SysOps and IFNA could be held legally responsible for the damage
resulting from negligently failing to take those countermeasures.
Quite apart from the legal consequences, a really devastating
virus attack would give the words "BBS" and "FidoNet" a brand
recognition somewhere between Tylenol and anal sex.
If the countermeasures aren't in place BEFORE major damage is
done, there will be an atmosphere of incredible paranoia about
using ANY software from BBSes and user groups. It could even be
quite difficult working on solutions in that atmosphere. Also
interests opposed to public domain software and the free exchange
of information could take the opportunity to impose regulation
and controls on a VERY unpopular minority.
3. WHAT IS TO BE DONE?
Fortunately there IS an approach that CAN stop viruses, and COULD
be widely used as soon as its available. I hope I've given enough
reasons for people to take a serious interest in my proposals
despite their unfamiliarity. Here goes.
The way biological immune systems develop antibodies to attack
foreign bodies is to first identify what SHOULD be present and
then deduce what should not. We can do that using "digital
signatures" just as the immune system recognizes molecular
signatures.
Since there is NO practical way to determine whether unknown
software is a virus or not, the ONLY feasible approach to "safe
software" is to identify KNOWN software and use nothing else.
The logic of that is both compelling and frightening. It has
FidoNews 5-26 Page 14 27 Jun 1988
already led to quite serious restrictions on the "promiscuous"
way that people exchange software. If the current trend
continues, open BBSes will become less and less viable and the
"free exchange of information" will be replaced by tightly
controlled distribution channels.
AT PRESENT the only way to identify "known" software, is through
writing and compiling it yourself, or buying it from a commercial
distributor in a shrink wrapped package. Even these precautions
aren't worth much against compiler viruses and given the level of
security at most software publishers.
Turned around, the same logic suggests we need to find another
way to identify "known" software. Fortunately there IS another
way, suitable for BBS public domain and shareware software.
3.1 Authentication by digital signature
Software authors and publishers can use public key encryption or
other digital signature techniques to authenticate their software
releases with their personal "signature". This merely requires
that they run a standard encryption utility on each package
before distribution. An explanation of how public key encryption
works is in FidoNews 428.
Authentication is the key to killing viruses while preserving the
free exchange of information. It doesn't actually kill them, but
it provides a way we can only use "known" software WITHOUT
tightly controlled distribution channels.
Essentially the use of public key digital signatures just
establishes that any two items that can be decrypted with the
same "public key" signature MUST have both come from the same
person. It's that person's personal signature and there is no way
that anybody else could "forge" it.
Because an item can be decrypted with a particular public key, it
must have been encrypted using the corresponding "secret key"
that was generated simultaneously with the public key by the
person who published that public key. Since this "secret key"
cannot be deduced from knowledge of the public key, the person
who encrypted using it must therefore be the person who published
the original public key (unless they let somebody else get hold
of a copy!)
A digital signature doesn't prove who the person that uses it
really is, or how trustworthy they are, or whether they
originally wrote the document they are signing.
But it DOES allow each software author (or other distributor) to
establish their own "reputation".
In practice most users won't want to keep the public keys of
large numbers of software authors and publishers, and new authors
and publishers need a way to get their software accepted.
FidoNews 5-26 Page 15 27 Jun 1988
This requires intermediary "recommenders" and "software
certifiers" who publish "signed" lists of signatures which they
recommend as trustworthy, or reissue software they trust under
their own "signatures". They may also issue signed "warnings"
about infected software they have come across, and who signed it.
Some SysOps and user groups may want to advise their users which
signatures they personally recommend as trustworthy. That's up to
them and it's up to their users what notice to take of their
advice.
Some software collectors may want to keep close tabs on who
releases what, and reissue copies under their own signature as
evidence that they consider an item to be uninfected. That's
equivalent to the responsibility that anyone takes now, when they
pass on a copy of ANYTHING to anybody else. A valuable service
can be performed by such "software certifiers". When things
settle down, end users should be able to rely on relatively few
signatures, and with the side benefit of automatically produced
catalogs of software available.
It's very important that there be convenient ways for
recommendations and warnings to be passed on and accepted or
rejected automatically according to users preferences as to which
advice they consider trustworthy. It's equally important that
there be no central authority who is the sole source of such
advice.
It IS possible for such "advice" to be processed automatically,
by users, with no hassles, despite coming from a multitude of
sources. I'll explain that later.
The essential point is that we ALL rely on such advice and
recommendations now, including published lists of Trojans. The
difference with my proposal is that we can automate it and know
where it's really coming from. More important, we can know which
software EXACTLY is being recommended or warned against.
Instead of lists warning about certain utility names and version
numbers, we will see (automatically processed) lists warning
about signatures. Although anybody can just adopt another
signature, getting other people to accept it will be a lot harder
than just using the RENAME command on a Trojan!
Life will actually be EASIER for SysOps as a result.
3.2 Establishing Reputations
For their recommendations and warnings to be accepted, a SysOp or
other software certifier needs a reputation for giving good
advice.
For their signatures to be recommended, or for their software to
be reissued under other people's signatures, a software author or
distributor needs a reputation for taking adequate precautions to
FidoNews 5-26 Page 16 27 Jun 1988
not release infected software. (For reissue most people would
want to read and recompile the source code themselves before
staking their own reputations on it.)
In both cases anybody can start again under another signature,
but the signatures that users will accept will be the ones that
have established a reputation over a period.
3.2.1 "I've never released infected software"
If an infected program is released under a particular signature,
anybody can PROVE that signature should not be trusted again.
(Although nobody can prove whether a virus was released
deliberately, accidentally, or as a result of allowing a secret
key to become known to somebody else, the effects are the same
and the consequences should be the same - don't trust the
signature of anybody who signed that software. They should never
have signed it. Whether it was deliberate or not is a matter for
law courts, not protection schemes.)
Proof consists of a copy of the infected software, as originally
signed by the person releasing it, together with details of the
infection, that can be tested by anyone reading about it.
3.2.2 "I've never signed bad advice"
If anybody gives signed bad advice that would be adopted
automatically by users who have decided to trust their advice,
anybody damaged can PROVE the advice was bad. Proof consists of a
copy of the signed advice, together with the proof that the
advisor got it wrong.
This can result in other software certifiers issuing signed
warnings to disregard advice from the signature that has been
proved to them to be unreliable.
Issuing a signed warning, without being able to provide the proof
when requested, can also be dealt with. Having asked for proof,
other software certifiers will be willing to stake their
reputations by issuing signed warnings that warnings from a
particular signature should be disregarded.
Signed warnings from software certifiers they trust can
automatically prompt users to revise their lists of who to trust,
and to review what software on their systems may be dangerous as
a result of having accepted bad advice.
Being able to PROVE these things, makes it possible to establish
a completely informal decentralized and automatic system for
distributing recommendations along with software. Such a system
can be fully automated so that it is almost completely
transparent to users, who only have to decide on accepting the
signatures of a few people whose recommendations and warnings
they will trust.
FidoNews 5-26 Page 17 27 Jun 1988
3.3 Implementation
All encrypted files would have a standard header including the
public key to be used (about 150 bytes). Decryption software can
look up the key (or a shorter hash of it) automatically in a
user's database of acceptable keys. Thus to decrypt a file, users
wouldn't even have to specify keys along with filenames. To
decide whether to trust some software, users wouldn't have to
look up their database manually. The key is either there or it
isn't, when the decryption software tries to process an encrypted
file.
Initially trusted signatures could be in standard format files
called PUBLIC.KEY, similar to individual nodelist lines. These
would normally be obtained direct by downloading or file request
from the trusted phone number contained within them.
Acceptance of those initial signatures as trustworthy would
result in automatic acceptance of subsequent files containing
recommendations or warnings signed with those signatures - until
the end user decides otherwise. After decrypting the
recommendation or warning the software would automatically apply
to the user's keys database.
Standard formats similar to the St Louis nodelist can be used to
distribute (signed) lists of recommendations and warnings about
particular public key signatures. Utilities similar to MAKENL and
XLATLIST (but with a "user friendly" interface) can be used
automatically together with the encryption software, to produce
customized end user databases of what signatures they will
automatically accept or reject.
End users just decide on a few signatures they INITIALLY consider
trustworthy, and then simply pass any encrypted files they
receive, whether software, recommendations or warnings, through
their encryption utility to automatically update their keys
database as well as to decrypt the software recommended by people
they trust and not warned against by people they trust.
The main complication for a full protection system is to avoid
the encryption utilities and key databases themselves becoming
infected, despite end users not fully understanding what it's all
about.
This can be achieved by writing the software so it HAS to be used
in a secure way, eg coldbooting from a "safe" floppy, encouraging
floppy backups of the encrypted versions of all software that is
accepted, and keyboard entry of checksums of PUBLIC.KEY files.
I'm drafting some proposed standards, specifications and end user
instructions for immediate and future software development.
Anyone interested in details of these proposals please file
request CRYPLIST from 1:221/162 for a list of what's available so
far. If anyone can suggest a simpler approach that is foolproof,
or can see loopholes in this one, please send NetMail to me at
1:221/162.14. Likewise for anyone interested in working on
FidoNews 5-26 Page 18 27 Jun 1988
software and standards. I'd like to start an echo, AREA:PUBKEY,
for serious discussions among interested software developers. It
really has to happen NOW.
3.4 Free Exchange of Information
Using this approach, software distributors, BBS SysOps and user
groups etc can freely distribute the encrypted versions of
software, recommendations and warnings from anybody, without
worrying about whether the software is infected or whether the
recommendations and warnings are reliable.
They simply notify end users not to accept anything that has not
been encrypted with a digital signature that the USER trusts
(whether directly or as a result of trusting recommendations and
ignoring warnings). The recommendations and warnings just get
distributed along with encrypted software.
This is an unfamiliar concept, but it can be implemented with
simple, "user friendly" utilities. It requires NO work "testing"
software and will ultimately be much easier to get across to end
users than the idea of software celibacy.
It also requires NO centralized authorities to put their stamp of
approval on things. Apart from the unlikelihood of such
authorities being established or accepted, there would be real
dangers of abuse judging from the way I've seen FidoNet
coordinators treat the nodelist. I'll be going into that in later
articles.
3.5 Isn't it too complicated?
Yes, for now. I'm hoping there will be SOME people who understand
AND agree with the point I'm making and will work on designing a
system as easy to use as possible for when its needed. Once its
needed, it will be needed BADLY, and the alternatives will be FAR
more complicated and basically won't work.
In that situation, which could come SOON, some SysOps and user
groups may go on distributing unencrypted software. But they will
lose popularity either gradually or very suddenly.
At least this proposal provides an alternative to pretending that
viruses can't get past detection utilities, and then wondering
why use of BBSes has suddenly become unpopular.
HOW safe to play it is up to each user. Some will be silly enough
to trust any PUBLIC.KEY they are offered. Each time their hard
disk gets trashed they will at least learn not to trust THAT
signature again, and eventually they may learn more. Once enough
users have been educated through experience, it will become
pointless attempting to release viruses - they aren't going to
travel far unencrypted and each signature used successfully is
going to reduce the number of gullible fools willing to accept
FidoNews 5-26 Page 19 27 Jun 1988
unknown signatures.
Of course some "software certifiers" may irresponsibly issue
software or recommendations under their signatures without
sufficient care. But they will quickly AND AUTOMATICALLY be
discredited and others more reliable will take their place.
Major software publishers will probably prefer to encourage users
to rely only on shrink wrapped factory fresh disks. They may even
welcome the additional incentive to do so. But they could end up
in the same position as religious moralists claiming that
monogamy is the only answer to AIDS. If a really devastating
virus gets out on a factory fresh diskette, that publisher will
probably go out of business and others may start publishing their
public keys in magazine ads and printed manuals (or shorter
hashes of the full keys).
3.6 How could this proposal get widely adopted?
End users that receive encrypted software and recommendations
distributed by BBSes, user groups or other end users are FORCED
to apply the encryption utility before they can use the software.
There are VERY good reasons why developers of FidoNet mailers and
related utilities should be using this system NOW, as I'm
explaining in a separate technical paper. If they do so,
responsible FidoNet SysOps will start accepting only the
encrypted versions (although initially decrypted versions would
continue circulating).
Once encrypted software starts being released, using it just
involves running the encryption utility on the files received,
with minimal inconvenience. Once FidoNet SysOps are doing that
for essential network software updates, it will be easy for other
software authors and publishers to adopt the same system and for
SysOps to make it available directly to their users. Thus the
system could take off rapidly, once it gains a foothold.
The "inconvenience" of running an encryption utility, can be
hidden by the "convenience" of having a system that automatically
keeps track of ALL the user's software installation and backups,
superior to the cataloging utilities available now and with the
advantage of automatic enforcement of use. It can also be
integrated with concepts like Megalist, for automatic tracking of
what's available and where to get it.
Keeping track is ESSENTIAL for virus killing, to recover from
having trusted irresponsible recommendations by restoring
original uninfected software, and to be able to track down,
remove, and warn others about, the signatures that caused the
problem. It has to be done automatically, or it won't be done
properly.
However this can be implemented later, after basic FidoNet
software has been protected by a preliminary system. Initially
FidoNews 5-26 Page 20 27 Jun 1988
FidoNet utilities could just be protected with publication of the
PUBLIC.KEY files of their authors, (eg in FidoNews, or shorter
hashes as nodelist flags), without the full mechanism for
exchanging recommendations and warnings and keeping track etc.
4. POSSIBLE PROBLEMS
4.1 Legal Hassles
The US National Security Agency has a policy opposed to the
widespread use of secure encryption techniques and has classified
some commercial public key encryption packages such as
Cryptmaster and PKcrypt as "weapons" subject to munitions export
controls. However this does NOT apply to publicly available
information including shareware and public domain software
available for download from BBSes (although some people have been
bluffed into believing it might).
Under the US Export Administration Regulations there is a General
Licence "GTDA" (part 379.3) which covers all such publicly
available technical data and is NOT overridden by the munitions
regulations (logical when you think about it - the US Government
is not so silly as to even TRY to prohibit export of publicly
available data!). Full details for anyone interested are
contained in a USEnet discussion as file GTDA.ARC (10K) available
for file request from 1:221/162.
Books containing detailed algorithms are readily available and
public domain or shareware source code would be in the same
category. (Some has already been released through BBSes and
USEnet).
I would recommend the following books for a thorough professional
understanding of secure cryptographic techniques:
Alan G. Konheim, "Cryptography: A Primer", John Wiley & Sons, New
York, 1981.
Carl H. Meyer and Stephen M. Matyas, "Cryptography: A new
dimension in computer data security", John Wiley & Sons, New
York, 1982.
4.2 Developing Encryption Software
Development of a standard public key encryption utility that can
be used widely involves no significant technical problems at all.
Its true that software with even the best key generation
algorithms runs extremely slowly, but each software author or
publisher only needs to generate their keys once and end users
don't need to do it at all (although there are extra benefits if
they do).
Actual encryption and decryption operates at quite acceptable
FidoNews 5-26 Page 21 27 Jun 1988
speeds with existing commercial packages and can no doubt be
further improved with the superior programming resources
available within FidoNet.
For our purposes a high speed "hybrid" implementation could be
quite acceptable, at least initially. This would use relatively
slow public key encryption to authenticate only a short hash of
the attached software, using a cryptographically secure hashing
method. The actual software need not be encrypted at all, but
just hashed with a more complex algorithm than the usual CRC and
producing at least 10 bytes of output. (That could also keep NSA
happy).
A smooth transition could be achieved by using a normal ARC file,
which can just be used to unARC the software directly or ALSO
used to check a file within it that contains the "signed" hash of
the rest of the ARC file. In the long run though, once things get
really bad, it would be better to force users to actually run the
software provided for authentication, by actually encrypting
entire files. The transitional system would be useful for secure
distribution of a better system released later.
I am writing a draft proposal for the FidoNet Technical Standards
Committee suggesting standards to ensure utilities developed will
be secure, compatible, fast, widely adopted, suitable for porting
to all common computers and suitable for other FidoNet uses.
(Other uses with further software development include: private
and authenticated Email; a convenient, decentralized and secure
means for exchanging nodelist information and session passwords
between nodes; and Email voting systems.)
4.2 Is Public Key Encryption Secure?
Most digital signature techniques rely on the computational
difficulty of factorizing large composite numbers. This problem
has defied mathematicians for some 200 years but has not been
proved cryptographically secure or even "NP complete" (a measure
of computational complexity which does NOT prove cryptographic
security). There is some indication that these methods CAN
eventually be cracked or MAY have already been cracked, with the
results classified.
Fortunately this problem need not concern us unduly as it is
unlikely that a major breakthrough in higher mathematics will
first come to light as a result of its discovery by someone
warped enough to want to launch destructive viruses! (Not that
some mathematicians aren't pretty warped, but they'd probably
prefer to take the public kudos for announcing the solution!)
If new developments make any particular digital signature system
insecure, alternatives are available and can be implemented
quickly. (Unlike virus detection programs which just simply won't
work AT ALL against the next generation of viruses.) Standards
for file headers etc should provide for later upgrades.
The main thing is to have the machinery in place for when its
FidoNews 5-26 Page 22 27 Jun 1988
needed, and improve it later.
4.4 Developing End User Software
Some pretty neat software will need to be written quickly for end
users automatic key databases and tracking etc. It has to end up
being a lot more professional and "user friendly" than most
public domain and shareware software and provide lots of extra
benefits like software cataloging, to gain wide acceptance BEFORE
a disaster hits.
That's why I wrote this article. Now who's going to do the hard
stuff?
Oh well, there it is. Sorry about the length, but if nobody pays
any attention, guess who'll be saying "I told you so".
-----------------------------------------------------------------
FidoNews 5-26 Page 23 27 Jun 1988
=================================================================
NOTICES
=================================================================
The Interrupt Stack
16 Jul 1988
A new areacode, 508, will form in eastern Massachusetts and
will be effective on this date. The new area code will be
formed from the current areacode 617. Greater Boston will
remain areacode 617 while the rest of eastern Massachusetts
will form the new areacode 508.
25 Aug 1988
Start of the Fifth International FidoNet Conference, to be
held at the Drawbridge Inn in Cincinnati, OH. Contact Tim
Sullivan at 108/62 for more information. This is FidoNet's big
annual get-together, and is your chance to meet all the people
you've been talking with all this time. We're hoping to see
you there!
24 Aug 1989
Voyager 2 passes Neptune.
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
-----------------------------------------------------------------
Latest Software Versions
BBS Systems Node List Other
& Mailers Version Utilities Version Utilities Version
Dutchie 2.90* EditNL 4.00* ARC 5.21
Fido 12h MakeNL 2.12* ARCmail 1.1
Opus 1.03b Prune 1.40 ConfMail 3.31
SEAdog 4.10 XlatList 2.86 EchoMail 1.31
TBBS 2.0M XlaxNode 1.02 MGM 1.1
BinkleyTerm 1.50 XlaxDiff 1.02
QuickBBS 2.01 ParseList 1.10
* Recently changed
Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.
-----------------------------------------------------------------
FidoNews 5-26 Page 24 27 Jun 1988
OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION
Ken Kaplan 100/22 Chairman of the Board
Don Daniels 107/210 President
Mark Grennan 147/1 Vice President
Dave Dodell 114/15 Vice President - Technical Coordinator
David Garrett 103/501 Secretary
Leonard Mednick 345/1 Treasurer
IFNA BOARD OF DIRECTORS
DIVISION AT-LARGE
10 Steve Jordan 102/2871 Don Daniels 107/210
11 Bill Allbritten 11/301 Hal DuPrie 101/106
12 Leonard Mednick 345/1 Mark Grennan 147/1
13 Rick Siegel 107/27 Brad Hicks 100/523
14 Ken Kaplan 100/22 Ted Polczyinski 154/5
15 Jim Cannell 128/13 Kurt Reisler 109/74
16 Vince Perriello 141/491 Robert Rudolph 261/628
17 Rob Barker 138/34 Greg Small 148/122
18 Christopher Baker 135/14 Bob Swift 140/24
19 Vernon Six 19/0 Larry Wall 15/18
2 Henk Wevers 2:500/1 Gee Wong 107/312
-----------------------------------------------------------------
FidoNews 5-26 Page 25 27 Jun 1988
FidoCon '88 - Cincinnati, Ohio
At The Drawbridge Inn and Convention Center
August 25-28, 1988
Attendee Registration Form
Name: ____________________________________________________
Address: ____________________________________________________
Address: ____________________________________________________
City: _______________________ State: ____ Zip: ___________
Country: ____________________________________________________
Phone Numbers:
Day: ____________________________________________________
Evening: ____________________________________________________
Data: ____________________________________________________
Zone:Net/
Node.Point: _______________________________________________
Your BBS Name: _______________________________________________
BBS Software: _____________________ Mailer: _________________
Modem Brand: _____________________ Speed: _________________
What Hotel will you be Staying at: ____________________________
Do you want to share a room? ______
Are you a non-smoker? ______
Do you want an in room point? ______
(Tower rooms at Drawbridge only)
Do you need special accommodations? ______
(If so, please explain) ____________________________
____________________________
FidoNews 5-26 Page 26 27 Jun 1988
Are you a non-Sysop? ______
Are you an IFNA Member? ______
If so, will you be attending the
Sunday IFNA brunch/BoD meeting? ______
Additional Guests: ______
(not attending conferences)
Comments: ____________________________________________________
____________________________________________________
____________________________________________________
Costs How Many? Cost
--------------------------- -------- -------
Conference fee $60..................... ________ _______
($75.00 after 7/31)
Thursday Lunch $10.95 .............. ________ _______
Thursday Dinner $18.95 .............. ________ _______
Friday Lunch $10.95 .............. ________ _______
Friday Banquet $24.95 .............. ________ _______
Saturday Lunch $10.95 .............. ________ _______
======== =======
Totals ................................ ________ _______
You may pay by Check, Money Order or Visa/MC
Please send no cash. All monies must be in U.S. Funds.
Checks should be made out to: "FidoCon '88"
This form should be completed and mailed to:
FidoCon '88 Registration
P.O. Box 9294
Cincinnati, OH 45209
If you pay by Credit Card you may also register by Netmailing
this completed form to 108/62 or 1/88 for processing. Please
complete the information below and be sure to include a voice
phone number above so that we can contact you for Credit Card
FidoNews 5-26 Page 27 27 Jun 1988
verification. Rename this file ZNNNXXXX.REG where Z is your Zone
number, N is your Net number, and X is your Node number.
[ ] Visa [ ] MasterCard
Name as it appears
on credit card: ___________________________________________
Credit Card Number: ___________________________________________
Expiration Date: ___________________________________________
Signature: ___________________________________________
(If you mail in registration)
-----------------------------------------------------------------
FidoNews 5-26 Page 28 27 Jun 1988
INTERNATIONAL FIDONET ASSOCIATION
ORDER FORM
Publications
The IFNA publications can be obtained by downloading from Fido
1:1/10 or other FidoNet compatible systems, or by purchasing
them directly from IFNA. We ask that all our IFNA Committee
Chairmen provide us with the latest versions of each
publication, but we can make no written guarantees.
Hardcopy prices as of October 1, 1986
IFNA Fido BBS listing $15.00 _____
IFNA Administrative Policy DOCs $10.00 _____
IFNA FidoNet Standards Committee DOCs $10.00 _____
SUBTOTAL _____
IFNA Member ONLY Special Offers
System Enhancement Associates SEAdog $60.00 _____
SEAdog price as of March 1, 1987
ONLY 1 copy SEAdog per IFNA Member
Fido Software's Fido/FidoNet $100.00 _____
Fido/FidoNet price as of November 1, 1987
ONLY 1 copy Fido/FidoNet per IFNA Member
International orders include $10.00 for
surface shipping or $20.00 for air shipping _____
SUBTOTAL _____
HI. Residents add 4.0 % Sales tax _____
TOTAL _____
SEND CHECK OR MONEY ORDER IN US FUNDS:
International FidoNet Association
c/o Leonard Mednick, MBA, CPA
700 Bishop Street, #1014
Honolulu, HI. 96813-4112
USA
Name________________________________
Zone:Net/Node____:____/____
Company_____________________________
Address_____________________________
City____________________ State____________ Zip_____
Voice Phone_________________________
Signature___________________________
-----------------------------------------------------------------
Reference in New Issue View Git Blame Copy Permalink