* Solar Designer <solar@private> [2006-07-04 02:46:28 +0400]:
> > I'd been debugging for most of the night, but still came up with nothing
> > concrete. I wish I had, but I didn't, so I'm still suspecting things
> > until I can actually find the culprit.
>
> Oh, I was implying that you would run the passwd program (or whatever
> else segfaults) under gdb and see just where the segfault occurs. It
> would not take that long to do.
Ummm... yeah... except I've never really used gdb too much before (yeah,
I know, I know...). I think I've only used it once before so I didn't
even think of using it (yes, I'm a sucker for punishment but I don't
usually deal with issues that are puzzles like this). gdb is on the
learn list.
> > > FreeBSD-style MD5-based
> > > [...]
> > > Iteration count
> > > 1000
> >
> > Interesting. I must have missed that when I was reading the manpage,
> > thanks. I didn't think that the count would have been the problem... is
> > "count" only useful for bcrypt then (in a real-world scenario)?
>
> Currently, variable iteration counts are supported for bcrypt and for
> the BSDI-style DES-based hashes ("prefix=_"). The latter are supported
> for compatibility with weird systems only, so you would most likely not
> use them in practice.
Ok, I see. So, most likely, it's really only useful with bcrypt unless
someone wants to get fancy.
> > Ie if someone wants to use md5 passwords, crypt should just be removed,
> > correct?
>
> (I assume that you meant "count", not "crypt".) Yes, that's correct.
Yes, sorry.
> > [vdanen@build SOURCES]$ perl -e 'print crypt("foo", "\$2a\$05\$abcdefghijklmnopqrstuu"), "\n"'
> > Segmentation fault
>
> OK, this suggests that the problem is in fact with crypt_blowfish or the
> way it is integrated or compiled. And I think that I know what it is -
> most likely, you need to increase BF_FRAME in x86.S:
>
> http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/x86.S.diff?r1=1.4;r2=1.5
>
> Sorry it did not occur to me to mention this to you before.
I don't think that was the problem. What I ended up doing was upgrading
to glibc 2.3.6 with the appropriate owl patches, but still found it was
crapping out on me. What I ended up doing was taking the patch that
SUSE was using and re-adding a few bits (they never touched
crypt/Versions so some symbols weren't being exported or available that
pam_tcb wanted which made authentication really interesting until I
figured that part out), and a few other bits.
After about a half-dozen glibc compiles and puttering around, bcrypt is
working now (strange... I've had it for over 2 years and never even
tried it so it's been broken all this time). At any rate, it might not
be perfect, but it's working with this patch (as opposed to the glibc
patch in the crypt_blowfish package itself):
http://svn.annvix.org/cgi-bin/viewcvs.cgi/releases/2.0-CURRENT/glibc/SOURCES/glibc-2.3-avx-suse-crypt_blowfish.patch?root=packages&rev=5738&view=markup
I suspect part of that might be the lack of _OW_SOURCE and friends being
defined here.
Bottom line is that bcrypt is working, I can create passwords now in tcb
without problem, and am slowly working out the remaining issues I'm
finding. They're fairly small, but I think I need to massage the
shadow-utils tcb patch a bit.
Right now I'm having an issue with userdel complaining that it can't
lock the shadow password file, so it's not deleting anyone. Other than
that, I think everything else is ok.
If nothing else, it's been a bloody challenge... =) Backporting
security fixes is much easier.
I may not be the smartest cookie in the jar, but I'm determined and if I
can lick everything that's come so far, this shouldn't be too terribly
difficult to accomplish either. I'm hoping to commit all my
pam_tcb-related changes to svn tonight or tomorrow when I fix this one
(hopefully last) issue.
> BTW, if this is indeed the problem, gdb would make it obvious immediately.
> You would see that the program crashes on a "hlt" - and there's only one
> such instruction in our stuff that you're integrating.
I'll have to move familiarizing myself with gdb higher on the list.
Anyways, thanks for all the brain prods... it's made me think.
--
{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/ ::
This archive was generated by hypermail 2.1.3 : Mon Jul 03 2006 - 21:03:28 PDT