[13543] in bugtraq

home help back first fref pref prev next nref lref last post

Re: NIS security advisory : password method downgrade

daemon@ATHENA.MIT.EDU (Darren Moffat - Solaris Sustaining)
Mon Jan 24 22:28:31 2000

Mime-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-Md5: mYFZTHAs54HdHi0jX4uyiQ==
Message-Id:  <200001241140.LAA05334@otis.UK.Sun.COM>
Date:         Mon, 24 Jan 2000 11:40:03 +0000
Reply-To: Darren Moffat - Solaris Sustaining Engineering <darren.moffat@sunuk.UK.Sun.COM>
From: Darren Moffat - Solaris Sustaining Engineering <darren.moffat@SUNUK.UK.SUN.COM>
X-To:         stefan@ASIT.RO
To: BUGTRAQ@SECURITYFOCUS.COM

>	The dish of the day is the Yellow Pages/NIS (NYS?) suite
>shipped with the pristine RedHat 6.1. After a standard blank installation
>the rpc.yppasswd (when used via ypasswd by  domain lusers from all over the
>place) shamelessly uses the old (deprecated?) 8-character-limited des

This is required to make it NIS(YP) otherwise it won't be able to
interoperate with other systems running NIS.  The md5 and other
alternate passwords are Linux/BSD extensions to the password table/map
that are not available in a lot of other UNIX systems.  Handing out md5
encrypted passwords means that is no longer NIS(YP) but some Linux
extension - if a commercial vendor did this lots of people would
complain about proprietary incompatible extensions to an open protocol.

It would be much better to run NIS+ or LDAP as your naming service if
you are concerned about people running password crackers over your
passwd table/map.  NIS+ and LDAP allow you to control which users can
actually see the encrypted password when a getpw*() call is made.  This
can be done because they have the concept of row & column permissions
much like a standard UNIX filesystem.

NIS has several other fundamental security short comings that have been
solved in NIS+ and other more modern naming services.  If you are
concerned about security of your naming service you really shouldn't be
using NIS at all.

>place) shamelessly uses the old (deprecated?) 8-character-limited des
>password encryption, butt-slapping the idea of site security and
>raising from their graves old pwcracks and John the Rippers that
>could easily bruteforce into your password files. Thus your new shiny
md5 >crypted shadow is gone, and the 8-chars passwords are back.

Secondly the encryption algorithm used in traditional UNIX passwords is
not itself limited to 8-chars.  Traditionally passwords in UNIX were
limited to 8-chars because login and friends called getpass() which is
defined to return a string of 8-chars + null.  Now Solaris, Linux and
possibly others use PAM and the PAM conversation functions tend to call
getpassphrase() or other functions (possibly GUIs) that make the new
limit 256-chars.


In summary I suggest that the Linux ypserv/rpc.yppasswd is not changed
to do this by default and it if it changed then it is made clear to
the admin when it is setup that enabling such a feature means they are
nolonger running traditional NIS(YP) and interoperability with other
systems will probably be broken and this is because they have enabled
this non standard extension.

--
Darren J Moffat

home help back first fref pref prev next nref lref last post