Dtlogin apparently explicityly sets its umask 027 and when it dumps core it can leave both encrypted and UNENCRYPTED passwords of remote users available via 'strings'.
Arve Kjoelen <akjoele@SIUE.EDU>
Narf passwords from dtlogin /core
Solaris 2.5.1 CDE with vulnerable dtlogin.
24 July 1997
Date: Thu, 24 Jul 1997 16:40:54 -0500
From: Arve Kjoelen <akjoele@SIUE.EDU>
Subject: Solaris2.5.1 dtlogin core
We're running Solaris 2.5.1 CDE remotely from some FreeBSD boxes.
The other day, I noticed a mod 644 core file in the root directory of
the Solaris machine. adb said it was dtlogin which had died of
SIGSEGV. Doing a 'strings' on the file revealed not only the encrypted
password of a remote dt user, but also the UNENCRYPTED password.
Adding umask 077 to the beginning of /etc/init.d/dtlogin does nothing. to
prevent this. Also, dtlogin is not affected by the modifications
discussed here earlier to set the default umask for all daemons (create
/etc/rc?.d/S00rootusr.sh containing 'umask 077'). It looks as if dtlogin
explicitly sets its umask to 027. ('nm' on /usr/dt/bin/dtlogin does find
a reference to umask).
Temporary fix: create an empty /core file mod 400. All subsequent cores
will be created with these permissions.
In general, I think all programs that process passwords should overwrite
the unencrypted password immediately after calling crypt(). There is
no reason to keep the unencrypted password around in memory.
Secondly, but not as critically, it would be nice if the
encrypted/hashed passwords could also be overwritten after they're no longer
> uname -av
SunOS cerberus 5.5.1 Generic_103640-08 sun4u sparc SUNW,Ultra-1
Sys Admin, EE Dept.
Southern Illinois University - Edwardsville.
The master index of all exploits is available
here (Very large file)
Or you can pick your favorite operating system:
This page is part of Fyodor's exploit
For a free program to automate scanning your network for vulnerable
hosts and services, check out my network mapping tool, nmap. Or try these Insecure.Org resouces: