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

Text File | 1993-01-25 | 7.8 KB | 158 lines

Newsgroups: comp.sys.novell
Path: sparky!uunet!usc!howland.reston.ans.net!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!usenet-feed.umr.edu!rfranken
From: [e-mail] (Richard Brett Frankenberger)
Subject: Re: Novell 3.11 security pitfalls?
References: <will.727121387@ogre> <[e-mail]> <[e-mail]>
Date: Mon, 25 Jan 1993 23:33:23 GMT
Nntp-Posting-Host: next5.cs.umr.edu
Organization: University of Missouri - Rolla, Rolla, MO
Keywords: security
Sender: [e-mail] (UMR Usenet News Post)
Message-ID: <[e-mail]>
Lines: 144

In article <[e-mail]> [e-mail] (Mark Muhlestein) writes:

>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:

I am glad someone from Novell responded (unoficially, of course, but that's
good enough for me) ...

I want to point out that I am not trying to berate Netware.  It is the best
NOS (IMHO) available for PC's and many other platforms also.  I am simply trying
to point out exactly what loopholes do exist, and to express my concern about
what I consider to be flaws in the way Novell handles the discovery of security
loopholes.

>>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.
>

I apologize to anyone who was mislead by my statement.  I am (and was) aware
that at NO TIME is an unencrypted password sent on the wire (not while logging
in and not while changing the password.  Of course, this assumes that
unencrypted passwords are NOT enabled on the file server).

However, I do not need this information to forge a packet-signature packet.
Since no public/private key (whereby a known public key is used to encrypt
something and a private key that is very hard to determine knowing only the
public key is used to decrypt it) methods are used, I can forge a packet-
signature packet if I know EVERYTHING that the server knows.  The server
does NOT know the user's password, as it is never sent in the clear.  Therefore,
I do not need to know the user's password.  I only need to know the encrypted
form of the password that the server has stored in the bindery, and I can find
this out by monitoring the wire while a user is changing his password.

>>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 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.

Keep in mind that, unless this implementd a public/private key system (which,
I think, would cause great performance reduction), I will be able to decrypt the
packets simply by knowing everything that has gone on (since "the beginning
of time") between the server and workstation.

Again, I can live with this risk.  It is not a problem for me, but people
should know exactly what is and is not possible.

>>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.
       [ Discussion about merits of telling public about loophole deleted ]

As stated below,it appears to me that Novell did have a fix to the KNOCK.EXE
hole but did not inform people about the loophole or the fix until the
hole was published to the net.

>>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.

It is my understanding that the patch was NOT released until well after 3.11
was out.  (I was not aware of the patch being released until about March or
April 1992, and the server I administer was running 3.11 since July 1992 or
so).  I therefore concluded that Novell knew about the bug sometime before
the release of 3.11 (June 1991 or before) but did not acknowledge it
and release a 3.10 patch until March or April 1992.  If the patch was
released at the same time (or before) NetWare 3.11 was released, then I am
mistaken and I apologize.

>>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.
>
Exactly.  So why wasn't the patch to fix 3.10 released at the same time
3.11 and 2.2 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.

Fair enough.  If novell was planning to fix this, I commend them.  As stated
I never meant to imply that Novell had more security problems than any other
OS.  NetWare is the most secure (IMHO) but it is not perfect.

>>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.
>
Why?  Because they can hope that no one will ever find it, and then the users
will never have to be told that it exists, which will make NetWare look better.
(A bad strategy, it would seem to me, as there are plenty of hackers out there
doing their best to find their way in).
>[e-mail]

     - Brett