owl-users - Re: tcb and friends with shadow-utils 4.0.12

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060703035214.GA16601@annvix.org>
Date: Sun, 2 Jul 2006 21:52:14 -0600
From: Vincent Danen <vdanen@...sec.ca>
To: owl-users@...ts.openwall.com
Subject: Re: tcb and friends with shadow-utils 4.0.12

* Solar Designer <solar@...nwall.com> [2006-07-03 04:38:07 +0400]:

> > I suppose the passwd
> > program would make sure the two entered passwords are identical and then
> > hand that password off to pam_tcb).
> 
> That's not how things work.
> 
> The PAM conversation function provided by the passwd program receives
> multiple echo-off input prompts from the PAM stack.  It does not know
> which of those prompts are for the new password, nor does it care.  In
> fact, for a text terminal interface, the passwd program may provide the
> standard PAM conversation function from libpam_misc rather than bother
> with its own implementation.

Ok, I think I'm understanding that now.

> With the configuration you had posted, the two new password prompts
> originate from pam_passwdqc.  If you remove pam_passwdqc from the stack
> and also remove the use_authtok option from pam_tcb, then the prompts
> will originate from pam_tcb.

Ahhh... ok.

> As it relates to the segfault you're seeing, I think it'd be most
> straightforward to debug it rather than proceed to theorize as to its
> possible cause.

I agree.  And I'm starting to suspect some misfiring in glibc and
crypt_blowfish.  I've been monkeying around and I'm suspecting that
crypt_blowfish is not properly integrated (which seems odd because all
my glibc patchs are owl-derived, but I may have goofed something in the
application or whatever).

At any rate, I've been fiddling with the options of pam_tcb and tried to
make it use regular md5 passwords by first changing "prefix=$2a$" to
"prefix=$1$", which didn't work.  I then tried removing the prefix
option and using "md5" in there, but now I'm seeing this in syslog:

authpriv.crit: passwd[2046]: pam_tcb(passwd:chauthtok):
crypt_gensalt_ra: Invalid argument

And I get authentication failures on trying even provide my user
password (passwd dies with "passwd: Memory buffer error.", using the ALT
passwd program).

So I tried using the "plain_crypt" option and I get the same thing.  In
fact, the *only* way I can make pam_tcb authenticate me is with having
the default "prefix=$2a$", or omitting it altogether (and not using
plain_crypt or md5 either).

Ok, now I'm not a C programmer, so I had to google for a sample piece of
code to use the crypt functions, particularly so I could see what, if
anything, was being returned for blowfish.  I found this bit of code:

#include <cstdlib>
#include <iostream>
#include <crypt.h>
using namespace std;

//compile: g++ hasher.cpp -o hasher -lcrypt

int main(int argc, char** argv){
        if (argc!=3)
	{
		cout << "Usage: $hasher <password> <salt>" << endl;
		return 1;
	}
	cout <<	crypt(argv[1], argv[2]) << endl;
	return 0;
}

[vdanen@...ld SOURCES]$ ./hasher foo '$1$salt'
$1$salt$nWwtt7njwVig74jTAfjuG/
[vdanen@...ld SOURCES]$ ./hasher foo '$2a$salt'
*0
[vdanen@...ld SOURCES]$ ./hasher foo '$2a$'
*0

Now that doesn't look right to me (I wasn't sure if the blowfish needed
a salt or not so I tried both).  It could be that my blowfish invocation
is wrong here too, which is why I'm getting the return I am; I've done
some poking around but can't find anything that gives me what an example
blowfish password should look like.  Well, I did find this:

http://www.openwall.com/lists/john-users/2005/07/02/1

and then tried hasher with '$2a$05' to try to simulate what I saw there
and still no dice, so I think something is messed up with my
glibc+crypt_blowfish integration.

Now, if pam_tcb is returning this "*0" (or receiving it when it's trying
to bcrypt what I type in), could that be causing the segfault?  Or was
this a bad code example to try to track the problem down?

I don't mean to sound like an idiot, and I hope I'm not coming across as
one, but encryption and C aren't my strong points... =)  So I'm trying
to do as much research/debugging as my limited skills in this area
permit, but this is the conclusion I'm coming to.  Am I way off base
here?  Or would a mis-application of crypt_blowfish be causing this (and
the other symptoms of pam_tcb not working properly with those other
options like "md5" and the like?).  Could it just be that pam_tcb is
unable to properly use the appropriate libcrypt functions?

I'm going to keep fiddling with this and re-compare my glibc spec to the
owl spec and also upgrade to 1.0.2 and see if I can come up with
something that works.  What I'd like to know is if that hasher program
will actually output blowfish passwords like I think it should.  I know
SUSE also has crypt_blowfish support so maybe I'll try compiling that
hasher program on my vmware install and see if it works properly.

Thanks, and sorry for the long message (kinda writing and testing things
at the same time).

-- 
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
mysql> SELECT * FROM users WHERE clue > 0;
Empty set (0.00sec)
:: Annvix - Secure Linux Server: http://annvix.org/ ::

Content of type "application/pgp-signature" skipped
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.