NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/novell/11895

Text File | 1993-01-25 | 5.3 KB | 113 lines

Newsgroups: comp.sys.novell
Path: sparky!uunet!pmafire!mica.inel.gov!ux1!fcom.cc.utah.edu!gateway.univel.com!ns.novell.com!ithaca.Eng.Sandy.Novell.COM!mmm
From: [e-mail] (Mark Muhlestein)
Subject: Re: Novell 3.11 security pitfalls?
Message-ID: <[e-mail]>
Keywords: security
Sender: [e-mail] (Usenet News)
Nntp-Posting-Host: ithaca.eng.sandy.novell.com
Organization: Novell, Inc.
References: <[e-mail]> <will.727121387@ogre> <[e-mail]>
Date: Mon, 25 Jan 1993 19:46:35 GMT
Lines: 99


Speaking for myself, and not as an official spokesperson for Novell, I
would like to make a few comments about the security issues Brett
Frankenberger brings up.  After pointing out (correctly) that
monitoring the entire login session would not allow a security breach,
he states:

>It would ALSO be necessary, in addition to monitoring the wire from the
>time NETX was run, to monitor the wire when the user changed his
>password.)

This is a bit misleading in that at no time is the unencrypted
password sent on the wire.

>To be totally secure, a method whereby I can monitor EVERYTHING EVER
>SENT between a workstation and the server, and still not get in, would
>be required.  (Of course, physically access is another issue).  So far,
>Novell does NOT have such a method, but they have made it VERY
>difficult to get in.  NetWare is not perfect, but it is VERY secure.

Novell has announced a future (1st half 1993) product which will
support packet encryption.  We believe this can be done with reasonable
performance, and it will provide a significant security enhancement for
those who need it.

>Unfortunately, some people, including me, will be forced to wonder what
>other loopholes out there.  It seems to me that Novell needs to revamp
>its security policy.

Although I can't speak for Novell, I think it is fair to say that the
company has been constantly increasing its concern for security.  The
only "policy" I know about here on the technical side of the company is
that when problems are found, we fix them.  The 4.0 release has several
very significant improvements in the security arena, and many of these
will be made available in maintenance upgrades to the 3.x products.

As far as publishing known "loopholes" it is well to remember that
there is a tension between the virtues of open dissemination of
information on the one hand, and concern for the security of the
installed base on the other.  I understand that there is some
controversy on this point.  But if I were the manufacturer of a safe
with a large customer base, and I discovered in-house that there was a
problem in the mechanism which allowed the safe to be opened by (say)
spinning the combination knob rapidly for 30 seconds, I would be very
hesitant to publish this fact before I was ready to provide a solution
to my customers.  And I think my customers would agree, if no one
had any reason to believe that anyone other than the manufacturer knew
about the weakness.  The problem is that there is no reliable way of
informing the "good guys" without also giving potentially damaging
information to the "bad guys".

>I think there is plenty of evidence that Novell knew about the hole
>that KNOCK.EXE exploited before KNOCK.EXE was released, and chose not
>to tell anyone, in hopes that no one would discover it and that way
>they would never have to admit there was a loophole.  It seems that
>they got a patch out pretty fast, if they had no advance knowledge.

This is not true.  The problem KNOCK.EXE exploited was a bug in the 3.0
and 3.1 password checking code which was not known until after it was
found by customers.  The patch merely fixed the bug, and 3.11 and 2.2
incorporated the fix in their initial release.

>Of course, this is not proof, as Novell does have plenty of sharp
>programmers.

Of course! :-)

>But, consider than 3.11 and 2.2 do NOT have the problem.  Did it just
>coincidentally disappear, or did they know there was a weakness, and
>fix it in future versions, but say nothing about it in hopes the public
>would never discover?

You seem to have your facts confused here.  As I explained above, the
reason 3.11 and 2.2 don't have the problem is that it was found and
fixed before they were released.

As far as HACK.EXE is concerned, obviously, forging packets is a known
security attack.  As Ron Holt mentioned the first time this topic came
up, a similar kind of attack as that used by HACK.EXE has been used to
exploit a weakness in the Unix NFS/YP security scheme (see the October
1992 issue of Computer Communication Review).  An approach to this
problem was contemplated for future release, but we were convinced that
we needed to implement it sooner than we originally planned because of
the publishing of HACK.EXE.

>Perhaps I am wrong, but I am of the opinion that if Novell were to
>discover a security hole today, they would patch it, and keep the
>patch, ready to release if anyone else disocvers the hole.
>
>       - Brett

Again, I can't speak for Novell, but why would anyone do this?  The
problems we have had in the past have been corrected as expeditiously
as possible, within the constraints of normal, accepted software
development methodology.  Our current products provide excellent
network security.  With the new products coming soon, I believe we will
continue a leadership role in this important area.

[e-mail]