Bug#445582: ldapscripts shows passwords in the clear on the command line
Hi Today, I had a look at the new upstream version 1.7.1, in order to fix unstable and testing. Thew new upstream version uses a function called mktempf () . There you generate the tempfile. However, you do not use the mktemp program. I did not try it so far, but I think that it is possible to guess the temp file, because you use _TMPFILE=$TMPDIR/`basename $0`.`date '+%Y%m%d-%H%M%S'`.$$ I would suggest using mktemp instead, which creates unique temporary filenames, which cannot be guessed. Cheers Steffen signature.asc Description: This is a digitally signed message part.
Bug#445582: ldapscripts shows passwords in the clear on the command line
On Sun, Oct 21, 2007 at 08:16:49AM +, Steffen Joeris wrote: Hi Today, I had a look at the new upstream version 1.7.1, in order to fix unstable and testing. Thew new upstream version uses a function called mktempf () . There you generate the tempfile. However, you do not use the mktemp program. I did not try it so far, but I think that it is possible to guess the temp file, because you use _TMPFILE=$TMPDIR/`basename $0`.`date '+%Y%m%d-%H%M%S'`.$$ I would suggest using mktemp instead, which creates unique temporary filenames, which cannot be guessed. what would be the point ? $TMPDIR is 0700. Cheers Steffen -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpnxRTPHIsbJ.pgp Description: PGP signature
Bug#445582: ldapscripts shows passwords in the clear on the command line
Hi I would suggest using mktemp instead, which creates unique temporary filenames, which cannot be guessed. what would be the point ? $TMPDIR is 0700. Bah, I overlooked the umask call. Thanks for the pointer. Cheers Steffen signature.asc Description: This is a digitally signed message part.
Bug#445582: ldapscripts shows passwords in the clear on the command line
On Thu, 11 Oct 2007 08:32:52 +0200 (CEST), Ganael LAPLANCHE wrote Hi everybody, ldapscripts v1.7.1 are now available and fix these issues. Here is the CHANGELOG : 2007/10/13 : ldapscripts 1.7.1 - Fixes for CVE-2007-5373 see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5373 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445582 1) Up to now, each ldap* command was called with the -w parameter, which allows to specify the bind password on the command line. Unfortunately, this could make the password appear to anybody performing a `ps` during the call. This is now avoided by using the -y parameter and a password file. - A new BINDPWDFILE option has been added : it specifies the path to the bind password file. This file can be created by something like : 'echo -n 'password' $BINDPWDFILE' and you can now safely remove (or comment) the BINDPWD parameter from your configuration file. 2) Changing a user password could also reveal the new password on the command line, because of the use of ldappasswd's -s option. This has been fixed by using a temporary file containing the new password (and ldappassword's -T option). - [internals] New mktempf() and reltempf() functions have been added [For older versions of OpenLDAP, -y and -T parameters may not be available. It is still possible to use the old BINDPWD parameter. Just uncomment it from the configuration file and comment the BINDPWDFILE parameter (which takes precedence over BINDPWD). The ldapscripts will just behave as previously and use inline -w and -s parameters, warning you this is not secure way of running them.] 3) A similar problem related to sed expressions has been found : it may also lead to reveal a user's password to `ps` users. This is now fixed by using temporary files containing sed expressions (and sed's -f option). 4) A new test has been added to check if 'echo' and '[' are built-in or not. If not, you'll be warned that the ldapscripts may not be safe to use (because these commands manipulate passwords when creating temporary files). - [internals] New is_builtin() function Note that these flaws depend largely on your kernel configuration : hardened kernels should not be impacted (e.g. if you use security.bsd.see_other_[u|g]ids sysctls on FreeBSD). It may also depend on the version of OpenLDAP client commands you run. Thanks a lot to Don and Madcoder for their help ! - Few fixes to avoid using non-standard 'if ! command's... Thanks a lot for your help in finding these issues ! (and don't hesitate to come back to me again if you find other problems related to the scripts) Best regards, Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445582: ldapscripts shows passwords in the clear on the command line
On Sat, 13 Oct 2007 13:37:25 +0200 (CEST), Ganael LAPLANCHE wrote On Thu, 11 Oct 2007 08:32:52 +0200 (CEST), Ganael LAPLANCHE wrote Hi everybody, ldapscripts v1.7.1 are now available and fix these issues. Woops, sorry I forgot to tell where the update is available : http://contribs.martymac.com/ldapscripts/ldapscripts-1.7.1.tgz http://www.sourceforge.net/projects/ldapscripts Best regards, Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445582: ldapscripts shows passwords in the clear on the command line
On Wed, 10 Oct 2007 20:55:04 +0200, Pierre Habouzit wrote If the server crash, then it will be rebooted, and /tmp is cleansed at boot time, so no worries here. Well, it depends on your system and how it is configured... But I agree, such a situation (crash /while/ using the script + /tmp not cleansed) may happen quite rarely. Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445582: ldapscripts shows passwords in the clear on the command line
On Mon, 08 Oct 2007 20:02:42 +0200, Pierre Habouzit wrote IMHO the best fix is to have in your runtime file sth like: [...] Hi again Pierre, I am still working on patching the scripts. This will lead to a 'security release' named 1.7.1, quite soon (I hope). Binding is Ok, I will use a file containing the password (no more $BINDPWD variable) and ldap commands' -y option. Anyway, I still think this 'flaw' should also be patched at openldap level when possible (setproctitle(3)). I still wonder if it is a good idea to use a temporary file for sed scripts. Trap is good, but what if the server crashes ? Is it better to be able to watch sed expressions during a few seconds with ps or to leave orphan temporary files on the disk forever ? Any idea ? Best regards, Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445582: ldapscripts shows passwords in the clear on the command line
On Wed, Oct 10, 2007 at 06:03:02PM +, Ganael LAPLANCHE wrote: On Mon, 08 Oct 2007 20:02:42 +0200, Pierre Habouzit wrote IMHO the best fix is to have in your runtime file sth like: [...] Hi again Pierre, I am still working on patching the scripts. This will lead to a 'security release' named 1.7.1, quite soon (I hope). Binding is Ok, I will use a file containing the password (no more $BINDPWD variable) and ldap commands' -y option. Anyway, I still think this 'flaw' should also be patched at openldap level when possible (setproctitle(3)). I still wonder if it is a good idea to use a temporary file for sed scripts. Trap is good, but what if the server crashes ? Is it better to be able to watch sed expressions during a few seconds with ps or to leave orphan temporary files on the disk forever ? Any idea ? If the server crash, then it will be rebooted, and /tmp is cleansed at boot time, so no worries here. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpWjiHET27Ii.pgp Description: PGP signature
Processed: Re: Bug#445582: ldapscripts shows passwords in the clear on the command line
Processing commands for [EMAIL PROTECTED]: forwarded 445582 [EMAIL PROTECTED] Bug#445582: ldapscripts shows passwords in the clear on the command line Noted your statement that Bug has been forwarded to [EMAIL PROTECTED] thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445582: ldapscripts shows passwords in the clear on the command line
forwarded 445582 [EMAIL PROTECTED]
thanks
FYI:
On Sun, Oct 07, 2007 at 03:54:43AM +, Don Armstrong wrote:
Package: ldapscripts
Severity: serious
Version: 1.4-2
Tag: security
Unless you're running grsecurity or some other patched kernel, the
following cannot be good:
_changepassword () {
if [ -z $1 ] || [ -z $2 ]
then
end_die _changepassword : missing argument(s)
else
if is_yes $RECORDPASSWORDS
then
echo $2 : $1 $PASSWORDFILE
fi
$LDAPPASSWDBIN -w $BINDPWD -D $BINDDN -xH ldap://$SERVER; -s $1
$2 2$LOGFILE 1/dev/null
fi
}
The issue may appear in other places in your code (there is e.g. some
unsafe seds calls). Though I must say I don't really know how to fix
this minimally.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpdjHjN4BR1T.pgp
Description: PGP signature
Bug#445582: ldapscripts shows passwords in the clear on the command line
Hi, The issue may appear in other places in your code (there is e.g. some unsafe seds calls). Though I must say I don't really know how to fix this minimally. my non-debian man page says: -y passwdfile Use complete contents of passwdfile as the password for simple authentication. That and a temporary file with correct permissions should do the job here? Haven't looked at the unsafe seds calls, though. Kind regards, Stefan
Bug#445582: Info received (Bug#445582: ldapscripts shows passwords in the clear on the command line)
Oops, disregard my previous message. Seems like I was a bit trigger happy and mixed it up with the -T parameter? -T newPasswdFile Set the new password to the contents of newPasswdFile. I managed to confuse myself right now and I'm not even sure if any of these params are OK at all. So better don't listen to me, sorry.
Bug#445582: ldapscripts shows passwords in the clear on the command line
On Mon, Oct 08, 2007 at 12:33:06PM +, Stefan Cornelius wrote: Hi, The issue may appear in other places in your code (there is e.g. some unsafe seds calls). Though I must say I don't really know how to fix this minimally. my non-debian man page says: -y passwdfile Use complete contents of passwdfile as the password for simple authentication. That and a temporary file with correct permissions should do the job here? Haven't looked at the unsafe seds calls, though. for the ldappasswd yes it can work this way (mkstemp will give the proper file, with the proper perms). FOr the sed calls it's less easy. I've not the time to fix that right now though. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpooDcIymLxR.pgp Description: PGP signature
Bug#445582: ldapscripts shows passwords in the clear on the command line
On Mon, Oct 08, 2007 at 02:57:42PM +, Ganael LAPLANCHE wrote: On Mon, 08 Oct 2007 14:10:21 +0200, Pierre Habouzit wrote Hi Pierre, Unless you're running grsecurity or some other patched kernel, the following cannot be good: $LDAPPASSWDBIN -w $BINDPWD -D $BINDDN -xH ldap://$SERVER; -s $1 $2 2$LOGFILE 1/dev/null Thanks for the forward. Two passwords appear in clear-text format here : $BINDPWD (the one used for any ldapscripts connection) and $1 (the new one, to be changed for a given user). The first one appears in any function defined in the runtime file (easy to grep : BINDPWD), the second one is only used in _changepassword() to change a user's password. Is it a matter of making the first one appear ? The second one, or both ? I understand these security issues, but my opinion is the scripts should only be used by a small set of users (e.g. *very* limited rx access to a specific user/group for config, runtime and script files). Since the password (at least the one used for binding) has to be sent clear-text to the LDAP directory, it has to be stored clear-text somewhere locally, and thus, any allowed user can source the conf file. I'm not sure storing it in a temp file would solve the problem... Any further explanation of the problem is welcome since I am not sure to understand the problem correctly... The issue is that when the commands are run, the arguments can be seen in clear text in `ps aux` output. So not only that script has the issue, the parts where you sed -e s/password/$PASSWORD/g are vulnerable too. I understand the issue is not that obvious to fix, but this is an issue in a multiuser environment, even if small (in my company we use ldap, we don't want our interns to run busy psaux loops to steal the ldap password …). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpvWCWJR9AQa.pgp Description: PGP signature
Bug#445582: ldapscripts shows passwords in the clear on the command line
On Mon, Oct 08, 2007 at 05:52:29PM +, Ganael LAPLANCHE wrote: On Mon, 08 Oct 2007 18:04:49 +0200, Pierre Habouzit wrote The issue is that when the commands are run, the arguments can be seen in clear text in `ps aux` output. So not only that script has the issue, the parts where you sed -e s/password/$PASSWORD/g are vulnerable too. Hi again Pierre, Yes, this is a really *big* issue. This is why one should prevent users to see processes running with another uid and/or gid (e.g. security.bsd.see_other_[u|g]ids sysctls on FreeBSD and hardened kernels on GNU/Linux) ! Unfortunalety, this is not always possible and there is no simple way to fix this flaw. Note this is not related to the ldapscripts : any admin running a 'standard' ldapadd command (or ldapmodify, ...) with the -w switch will encounter the same problem. I'll try to have a look at it. The idea of a file containing the passwd could be good... Any other idea is welcome :) IMHO the best fix is to have in your runtime file sth like: $SAFE_TMPDIR=`mktemp -d` || die unable to create safe temporary directory trap rm -rf $SAFE_TMPDIR 0 This way, when any script ends, all the temporary safe directory gets removed. Then you can create whichever file you want, even using predefined filenames if you want to. sed and ldappasswd are both able to read their commands in a file. Also one could argue that echo $PASSWD is safe in many shells where echo is a builtin. You could ensure that it's the case using: if ! (type echo || die shell has no 'type' builtin) | grep -q builtin; then die echo is not a builtin, ldapscripts won't be safe fi I tried in bash, dash, posh and zsh. it detects properly that posh isn't suitable. So that you can build the sed scripts using: echo $PASSWORD foo.sed in a safe way. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpRkIutkwFqJ.pgp Description: PGP signature
Bug#445582: ldapscripts shows passwords in the clear on the command line
On Mon, 08 Oct 2007 18:04:49 +0200, Pierre Habouzit wrote The issue is that when the commands are run, the arguments can be seen in clear text in `ps aux` output. So not only that script has the issue, the parts where you sed -e s/password/$PASSWORD/g are vulnerable too. Hi again Pierre, Yes, this is a really *big* issue. This is why one should prevent users to see processes running with another uid and/or gid (e.g. security.bsd.see_other_[u|g]ids sysctls on FreeBSD and hardened kernels on GNU/Linux) ! Unfortunalety, this is not always possible and there is no simple way to fix this flaw. Note this is not related to the ldapscripts : any admin running a 'standard' ldapadd command (or ldapmodify, ...) with the -w switch will encounter the same problem. I'll try to have a look at it. The idea of a file containing the passwd could be good... Any other idea is welcome :) Best regards, Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445582: ldapscripts shows passwords in the clear on the command line
Package: ldapscripts
Severity: serious
Version: 1.4-2
Tag: security
Unless you're running grsecurity or some other patched kernel, the
following cannot be good:
_changepassword () {
if [ -z $1 ] || [ -z $2 ]
then
end_die _changepassword : missing argument(s)
else
if is_yes $RECORDPASSWORDS
then
echo $2 : $1 $PASSWORDFILE
fi
$LDAPPASSWDBIN -w $BINDPWD -D $BINDDN -xH ldap://$SERVER; -s $1 $2
2$LOGFILE 1/dev/null
fi
}
Don Armstrong
--
This message brought to you by weapons of mass destruction related
program activities, and the letter G.
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
