The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #318 [Re: Mailbridges down] (1 message, 1898 bytes)
SOURCE: http://securitydigest.org/exec/display?f=phage/archive/318.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

From: rick@seismo.CSS.GOV (Rick Adams)
To: phage
Date: Fri 13:47:21 02/12/1988 EST
Subject: Re: Mailbridges down
References: [Thread Prev: 315] [Thread Next: 317] [Message Prev: 319] [Message Next: 320]

As I understand things:

Someone broke into mitre with the ftpd bug.

DCA shut off the mailbridges until they got a "bug free" ftpd to
replace the ones on the MILNET sites (Ever see a program that you could
guarantee bug free?)

They wanted NSA to certify that the ftpd program from Berkeley was
absolutely secure and they weren't going to turn on the mailbridges
until then.

NSA quoted 3-4 months to certify a program as secure.

Keith Bostic and I talked about it on the phone and got ISTO to accept
the following scenario.

Bostic would package up what he felt was a fixed ftpd. He would submit
it to "an independent expert" who would validate it as an interim
solution, pending the official NSA blessing.

I became the independent expert (probably because Keith had my home
phone number...). I spent an exciting 6 hours from 8pm to 2am reading
through the ftpd source and getting Keith to correct anything that
looked even remotely suspicious. I found 2-3 real bugs [not security
bugs, but things like if (getchar()&0377 == EOF) ] in the logic and
about 7-8 "questionable" bits of code.

Keith changed all of the questionable sections of code to my
satisfaction and we gave the fixed version to someone at ISTO, who
convinced DCA that it was an acceptable solution. I have a high degree
of confidence in the current code.  I won't call if bug free because I
believe that no "real" program can be guaranteed totally bug free.
(Especialliy in 6 hours!)

I intentionally wrote none of the fixes so that I wouldn't assume
anything.  The method of having one person write the code and another
one critiquing it seemed to work well. The resulting distribution is
pretty solid.  There are still one or two "odd" things in the code.
Keith and I have convinced ourselves that they are not security
problems. However we have no idea what function they are supposed to
serve. We chose not to remove them until we were sure that it wouldn't
break anything. Keith is tracking down the person who originally wrote
those parts of code and will ask him what they are supposed to do.

Anyway, the mailbridges were turned on late last night. I dont know if
an official explanation of the problem will appear. (It certainly SHOULD!)

You can treat my part of the story as first hand. I really dont know
much about the problems at mitre and the decision process at DCA.
I got into it at the "the problem exists lets fix it" stage and didn't
really take the time to obtain all the background information firsthand.

However, it is totally inexcusable that the New York Times was putting
out better information that the so-called "Network Information Centers"
and "Network Operations Centers". The nonsense about a software glitch
taking out all of the mailbridges and then deciding to "test" how the
Internet performs while servered is totally unbelievable and strong
measures should be taken to prevent this kind of disinformation from
occuring again. I doubt if even a non-technical reporter would have
believed that story. I'm sure none of the technical types who were
trying to figure out what was going on would believe it.

There is hope! A group is being set up to handle future problems like these.
It will have "real" technical people in it to make the technical evaluations
(E.g. Mike Karels and Keith Bostic are "founding" members). It will take
a while to get up to speed, but in the near future, I think problems
like this can be avoided.

---rick

END OF DOCUMENT