I received replies from several people; thanks go to:
Dag Gano, dgano_at_ss.ca.gov
John Speno <speno_at_isc.upenn.edu>
Nathan Grass <NathanG_at_UTS.Itron.com>
and one who requested I didn't publish the name...
I think this is probably a matter to take up with our account rep...
Digital really need to look around at what other vendors are doing - eg,
http://www/sgi.com/support/security. Even Microsoft are doing a better
job here - their software implementations may stink, but their security
web page is useful. This is really just another aspect of marketing, so
I suppose the situation is not entirely surprising...
Replies are below, followed at the end by the original question.
>From: dgano_at_ss.ca.gov
>
>I may be completely wrong here, but I believe it is because Digital UNIX
>is simply less vulnerable than Sun and some others. I'll be looking
>forward to hearing what you find out in your SUMMARY.
I do feel that Digital UNIX seems to have far fewer problems than Sun
and SGI, however, I also feel that when there *is* a problem, the
amount of information sharing, and speed of providing a fix is not
as good as it should be.
From: John Speno <speno_at_isc.upenn.edu>
>Digital doesn't seem to respond to security issues nearly as well as
>other vendors.
>
>I was talking to an ex-CERT person recently, and when asked which
>vendor was the worst WRT responding to security issues, he said
>'Digital - always was, still is'. Of course that's paraphrased.
>
>Digital can almost get away with this. Most exploits available on the
>net don't work on Digital Unix (alphas). Still, it obvious that they
>need to improve in this area, and I hope they will.
This response echoes my feelings precisely...
From: Nathan Grass <NathanG_at_UTS.Itron.com>
>The lack of information is likely caused by the rapid development of CERT
>Advisories. Check back on the advisory for updates after some time has been
>given to DEC to fix the problem. Also checking on this list (since many DEC
>employees are on it) is a good way to find out if/when a solution is
>available.
>
>The "investigating" stance is taken by many companies when they don't have
>any definite answers to give.
Fair enough, but the BIND exploit was many months ago, and we still have
no fix from the vendor. We may simply be lucky in that no-one (that we
know of) has attempted the buffer overflow using code directed against
our CPU and OS.
>From anonymous:
>
>There is an organization in Digital called the SSRT
>that tracks all security issues
>related to Digital's products.
>
>
>Chuck Noble, SSRT Program Manager
>
>Rich Boren, SSRT Operations Manager
>
>+ a web page is also available:
>
>http://www-ogc.ecom.dec.com/corpsec/ssrt.htm
I didn't reproduce the contact phone numbers and email addresses,
because I didn't feel sure if it was appropriate. I've passed them on to
our campus security contacts, though I doubt they will have time to
perform any neccessary harrassment. I found that the web URL above
doesn't work for me, though (no response).
Finally, here's my original question:
> Extracted from CERT* Advisory CA-98.10
> Original issue date: August 11, 1998
>
> >Hewlett-Packard Company
> >=======================
> >
> >The version of dtmail supplied by HP, as part of HP's CDE product, is
> >vulnerable. Patches in process.
> >
> >Sun Microsystems, Inc.
> >======================
> >
> >Sun Microsystems is working on patches for the following products:
> >
> > dtmail
> > * CDE versions 1.0.1, 1.0.2 and 1.2.
> > * Patches will be available within three weeks
>
> My question is simple: is Digital UNIX dtmail similarly vulnerable?
> ("yes" would seem to be the safe assumption!).
>
> And if so, is a patch planned?
>
> Finally, either way, I notice Digital-related information is often
> conspicuously missing from such announcements - for example, back in
> April, when we had the BIND vulnerability alert, the only Digital UNIX
> information was "Digital is investigating this problem.". I don't
> believe we heard anything since. Is there any reason for this lack of
> information?
>
> Graham
Received on Fri Aug 14 1998 - 19:39:47 NZST