[OT] LDAP vs NIS+ security

[OT] LDAP vs NIS+ security

[Trever L. Adams]

I am sorry to write this off topic message.  I should probably go look 
in google for the answer... however -

Someone in arguing about implimenting directory services into the kernel 
said that NIS+ will always be more secure than LDAP over SSL... why is this?

Trever Adams

Re: [OT] LDAP vs NIS+ security

[Michael H. Warfield]

On Sun, Sep 09, 2001 at 10:07:06PM -0400, Trever L. Adams wrote:
> I am sorry to write this off topic message.  I should probably go look 
> in google for the answer... however -

> Someone in arguing about implimenting directory services into the kernel 
> said that NIS+ will always be more secure than LDAP over SSL... why is this?

	FIIK...  /;-(

	NIS (FKA Sun Yellow Pages) was so insecure it became know as
the "Network Intruder Service".  NIS+ was suppose to address most of
the NIS security issues and it did to a large extent, but created
more than a few problems along the way (having had to managed a mixed
Sun OS 4.x and Solaris 2.x environment, I have more than my share of
horror stories).

	AFAIK, there is no NIS+ server on Linux.  The home page for the
NIS+ utils states it quite plain that there is no Linux server and there
appears to be no prospect of there EVER being and NIS+ server on Linux
(reasons are unstated there, but I have heard comments about closed
protocols and proprietary information and refusals to release critical
information).

	Also, AFAIK, while NIS could support nice things like MD5 password
hashes, NIS+ can not.  Now, I haven't verified this personally, but that
would seem to be a highly UNACCEPTABLE step backwards if NIS+ can not
support higher grade password hashes and long pass phrases!

	Sooo...  Why in bloody hell would we want to lock ourselves into
a proprietary system which would force use to depend on servers based on
other systems and force us to use decidedly inferior authentication
standards?  That certainly doesn't sound "more secure" to me.

	Then too, what grade cryptography is NIS+ using?  I know it
uses Public Key crypto in setting server credentials, but I don't know
if it uses DES or 3-DES in the secure RPC channels.  At one time it was
DES.  If it's still single DES, that sucks and is decidedly insecure.
SSL gives use 128K symetrical encryption.  That should be a minimum.

	If they claim that NIS+ will always be more secure than LDAP
over SSL (and I really DON'T know either way) then have them specify
the exact justifications for that claim.  Also have them justify
why we should accept a closed standard which we can not participate
in as a server.  Also have them justify why we should place ourselves
in a subordinant position, dependent on a closed source server for
our authentication services.  Also have them justify, why we should
accept degraded security in the authentication systems by being forced
to accept the old style DES hashes and 8 character limits on passwords.

	I just don't see where NIS+ can be justified as even being
qualified for the discussion.

	But then again...  Maybe times have changed and all these concerns
are just out of date.  If so, then were is my Linux based NIS+ server?
I would like to have a copy of that.  Then to, maybe the horse will learn
to sing (r.e. ancient Chinese fairy tale).

> Trever Adams

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Re: [OT] LDAP vs NIS+ security

[Michael H. Warfield]

On Sun, Sep 09, 2001 at 11:40:39PM -0400, Michael H. Warfield wrote:
> On Sun, Sep 09, 2001 at 10:07:06PM -0400, Trever L. Adams wrote:
> > I am sorry to write this off topic message.  I should probably go look 
> > in google for the answer... however -

> > Someone in arguing about implimenting directory services into the kernel 
> > said that NIS+ will always be more secure than LDAP over SSL... why is this?

> 	FIIK...  /;-(

> 	NIS (FKA Sun Yellow Pages) was so insecure it became know as
> the "Network Intruder Service".  NIS+ was suppose to address most of
> the NIS security issues and it did to a large extent, but created
> more than a few problems along the way (having had to managed a mixed
> Sun OS 4.x and Solaris 2.x environment, I have more than my share of
> horror stories).

	Oh!  Almost forgot the best one of all (and more related to
the directory service issue than problems with the password map).

	If you combine YP/NIS/NIS+ with something like the finger
service and you have a large enough user identification base, you
create this niffty DoS attack that I called "nisnuke" at the time
I published the security advisory years ago.

	Basically, if you have a sufficiently large user database and
I can get to enough finger servers, I can time finger requests into an
NIS* network in a way that crushes the INTERNAL bandwidth destructively.
With an experimental setup of only 10 finger servers and 1,000 users
in the NIS maps I was able to uses a 30 second blast from perl script to
cripple the test network for over 30 minutes.  While most Linux systems
recovered quickly, Solaris boxes took minutes to recover (most Solaris
boxes had the screen savers freeze during the resulting NIS "storm") and
some AIX boxes had to be power cycled.  Most boxes would not even toggle
the "caps lock" light on the keyboard during the meltdown period.

	Note that the storm of NIS traffic cripples the internal bandwidth
between the finger servers and the NIS[+] servers.  This takes out everyone
on that network, not just the NIS and finger servers.  The conditions
create a situation where RPC retries and failures (due to collisions)
actually exceed the input to the cable you are generating from the
finger traffic.  It's a queueing theory meltdown where the input to
the queue is higher than it's capacity.

	Sun worked for months trying to solve the problem and the best they
could come up with was to either "disable finger" or "install and open
source version of the finger service which did not do wild card expansion
on the databases".

	This was all documented in an Internet Security Systems Advisory
which I authored several years ago.  AFAIK, if you put an NIS or NIS+
network together with a large enough user base and a few finger servers,
I can cripple it with NIS traffic and tear it to it's knees and keep
it there.  And all finger is doing is "directory lookups" on users.  :-/

	See BugTraq or ISS Alert archives for more information.

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!