bukys@CS.ROCHESTER.EDU (11/07/88)
The never-ending debate in computer security circles is whether to publicize bugs, or to hide them, hoping the vendor will fix them, someday. Whatever ones opinions are in this matter, it is clear that the widespread public embarrassment caused by the worm escapade will lead to a quick response from the vendors. Failure to act doesn't look very good when "the network is the computer". In light of the power of public embarrassment, here is a modest proposal. It does NOT address the problem of a malevolent cracker discovering a hole and instantly exploiting it. It does address the problem of any vendor's reluctance to fix bugs or publicize them within a reasonable time. (1) Set up an Internet Security Accountability (ISA) organization. Vendors subscribe to its services for some reasonable amount. Failure to subscribe brands a vendor as one which does not care about security lapses. (2) Vendor subscription requires that vendor supply access (to ISA) to complete source code to every release of software, and in a timely manner. (3) ISA employs a crack team of crackers to find security holes in the systems. When a hole is found, the bug is reported back to the vendor. Vendor has two weeks in privacy to produce official patches, which are to be made immediately available to ISA and the user community. (Patches should have no restriction on copying.) A vendor response of "upgrade to release X.Y" is not adequate when the previous release is not all that old. (4) Whether or not the vendor produces the patches, when the two weeks is up, ISA announces the existence of the bug, its ramifications, and the vendor's patches, if any. If there aren't any patches yet, the vendor's phone rings off the hook, and various customers get steamed and cancel orders, etc. (5) At the end of that hot two weeks, ISA announces any workarounds that it has devised, or pronounces the system and vendor hopeless for now. One hopes that the stigma attached to the latter is painful enough that vendors will avoid it. ISA could publish a newsletter, containing the current inventory of known bugs and official patches. Available by anonymous ftp, of course. Maybe this is all too grandiose. On the other hand, I think that there are plenty of responsible people out there who would love to submit bugs reports, if only there were someplace they could send them where they would have some effect. So the crack staff wouldn't have to be very large, since the community would be providing a lot of "free" expertise. As to whether vendors could be made to go for it: there are lots of things that vendors don't like that they submit themselves to because the market requires it. Certification of X.25 protocol implementations, for instance. Now, will the market require it? Liudvikas Bukys <bukys@cs.rochester.edu>
BILLW@MATHOM.CISCO.COM (William Westfield) (11/08/88)
Interesting that you should mention X.25 certification as an example. It is true that the market requires X.25 certification, but the procedures and tests them selves are pretty much a joke. The other problem is that I doubt whether you can get "a crack team of crackers" to spend weeks or months pouring over the source code of some random operating system looking for security flaws, and still get vendors to pay only "a reasonable amount". I don't see how this could cost any less than $100K/release. There is always the current practice of "beta test at a university", or "put it on the internet", which is a pretty reasonable test. The weakest point is still the users.. The sad part about this particular incident is that the sendmail hole has apparently been known to quite a large number of people for a long time. (After all, sendmail is not proprietary to any vendor, and source are widely available.) No one did anything about it. It is approximately true that the Internet is NOT overly concerned with security. The current incident has pointed out that perhaps we should be somewhat more concerned. Bill Westfield cisco Systems. -------
fair@APPLE.COM (11/08/88)
This has a flaw: suppose a member company sues ISA for defamation (or whatever else their legal department thinks up)? ISA had better have a very good legal department to go over all its public pronouncements, and defend it against litigation. Also, if ISA goofs... Erik E. Fair apple!fair fair@apple.com
avolio@decuac.dec.com (Frederick M. Avolio) (11/08/88)
Just thought I'd mention that there is a corporation called ISA ... Don't remember what ISA means (isavax.isa.com would know). Anyway, this talk -- hypothetic to be sure -- of suing ISA, etc is going to make one cheif scientist of ISA real nervous if he ever saw these notes :-). fma
hd@kappa.rice.edu (Hubert D.) (11/09/88)
I'm on the other side of the fence. The death bell of commercial network software may be tolling. I wonder if my site will install ANY code we don't have source for. We've been looking at software to connect our PCs and MACs to SUNs and VAXn. Now, with the possibity of holes and backdoors left in place by software vendors, I don't see how one can trust object code for communications software anymore. I'm going to take a hard think on wheather to go commercial or install/modify/develop public domain packages such as KA9Q, NCSA or PCIP (MIT & CMU). Hubert Daugherty hd@rice.edu References: <8811071557.AA03126@hamal.cs.rochester.edu> Sender: Reply-To: hd@kappa.rice.edu (Hubert D.) Followup-To: Distribution: Organization: Rice University, Houston Keywords:
root@sbcs.sunysb.edu (root) (11/09/88)
A quick comment on the distribution of bug fixes. One hopes that other vendors will NOT follow the example of SGI and just post patched binaries to Usenet. They had shipped a complete uuencoded binary in comp.sys.sgi; such a practice leaves entirely open the possibility that some could introduce a trojan horse along the way. Of course this leaves open the question of whether any of us *really* read through the various PD sources we import... Scary this virus and what it may lead to. Rick Spanbauer SUNY/Stony Brook
ron@ron.rutgers.edu (Ron Natalie) (11/10/88)
I don't know why you say that. Many of the infected sites had source for sendmail. As a matter of fact, we had done some local modifications to it and were mildly familiar with the code and we were still hit. We were still hit after I had ripped out all the ifdef DEBUG code out of an earlier release of sendmail due to an even more BLATENT security bug that the one recently divulged. We got a new release with the earlier bug fixed and people figured that we didn't need to go to the effort of ripping all that stuff out again. -Ron
root@sbcs.sunysb.edu (root) (11/10/88)
In article <2120@kalliope.rice.edu>, hd@kappa.rice.edu (Hubert D.) writes: > We've been looking at software to connect our PCs and MACs > to SUNs and VAXn. Now, with the possibity of holes and > backdoors left in place by software vendors, I don't see > how one can trust object code for communications software > anymore. I'm going to take a hard think on wheather to > go commercial or install/modify/develop public domain > packages such as KA9Q, NCSA or PCIP (MIT & CMU). Huh? If you let anyone on your Ethernet cable with a PC you've basically just given up any hope for security. Even active methods like Kerberos will not protect you from people who just listen to eg TCP sessions on the cable. > Hubert Daugherty > hd@rice.edu Rick Spanbauer SUNY/Stony Brook
bet@dukeac.UUCP (Bennett Todd) (11/18/88)
In article <1801@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes: ->In article <2120@kalliope.rice.edu>, hd@kappa.rice.edu (Hubert D.) writes: ->> We've been looking at software to connect our PCs and MACs ->> to SUNs and [...] -> Huh? If you let anyone on your Ethernet cable with a PC you've -> basically just given up any hope for security. Even active -> methods like Kerberos will not protect you from people who -> just listen to eg TCP sessions on the cable. Are you sure about that? I thought I sorta understood Kerberos, and that it was distinguished as the only authentication protocol that was robust and secure in the face of hardware eavesdropping, interception, and injection of messages. The "dialog" is pretty fun reading, and explains the contortions -- and the reasons for going through the contortions -- pretty clearly. -Bennett
hwchoy@zpovc.DEC.COM (Heng-Wah Choy DEC Singapore SWS) (11/21/88)
Hi Hubert Daugherty {hd@kappa.rice.edu}
for a secure Ethernet, look at DEC's DESNC Ethernet encryption box.
Cheers
Heng-Wah Choy
Software Specialist
Singapore Software Services
{ZPOSWS|ZPOVC|ZPOACT}::HWCHOY
Heng-Wah Choy @ ZPO