Re: kpasswdd dumps on OpenBSD6.3

> On Aug 3, 2018, at 5:27 AM, ASV <[email protected]> wrote:
>=20
> Changing password as suggested (kadmin -l cpw ...) works

No crashes, right?  Modulo authentication of the user, UDP transport, =
...
ultimately "kadmin -l cpw" and "kpasswd" should end up calling the
same change() function in much the same way.

> After starting back the daemon it worked well.

What does "it worked well" mean?

> I'm using the HDB3 which I believe is part of the package itself (if I =
properly understood your question).

Yes, thanks.

> This is the output of the procedure on the newly re-compiled heimdal =
with the CFLAGS=3D"-g -ggdb3 -O0" but doesn't look much different from =
the previous non-debugging version to me (hopefully I didn't make any =
mistake).

It looks like something stripped the built binaries, please make sure =
your
build process does not strip the binaries, and that you're running the
binaries with the debug symbols.

> A snippet of the compilation at the very end of this email.
>=20
> (gdb) bt
> #0  0x00000ae0709ed5d6 in change () from =
/usr/local/heimdal/lib/libkadm5srv.so.3.0
> #1  0x00000ae0709ed55f in kadm5_s_chpass_principal_cond () from =
/usr/local/heimdal/lib/libkadm5srv.so.3.0                                =
                                                   =20
> #2  0x00000ade6d002bfb in ?? () from =
/usr/local/heimdal/libexec/kpasswdd
> #3  0x00000ade6d001b89 in ?? () from =
/usr/local/heimdal/libexec/kpasswdd
> #4  0x00000ade6d0017d9 in ?? () from =
/usr/local/heimdal/libexec/kpasswdd
> #5  0x00000ade6d001073 in ?? () from =
/usr/local/heimdal/libexec/kpasswdd
> #6  0x00000ade6d0009a6 in ?? () from =
/usr/local/heimdal/libexec/kpasswdd
> #7  0x0000000000000000 in ?? ()
> (gdb) x/i $pc
> 0xae0709ed5d6 <change+102>:     cmpl   $0x0,0xc8(%r14)

This is a structure member dereference at offset 200 from
a structure at $r14, which we see below is a NULL pointer:

> (gdb) i reg
> rax            0x76118487c2646c07       8507726889696390151
> rbx            0x1      1
> rcx            0x0      0
> rdx            0x1      1
> rsi            0xae13fbbe1a0    11962553196960
> rdi            0x0      0
> rbp            0x7f7ffffd58b0   0x7f7ffffd58b0
> rsp            0x7f7ffffd57a0   0x7f7ffffd57a0
> r8             0x0      0
> r9             0xae13fbbe4e0    11962553197792
> r10            0xae0a1066ab0    11959890504368
> r11            0xae0a299e000    11959916945408
> r12            0xae13fbbe1a0    11962553196960
> r13            0x0      0
> r14            0x0      0
> r15            0xae13fbbe4e0    11962553197792
> rip            0xae0709ed5d6    0xae0709ed5d6 <change+102>

Looking at the code for change(), this seems to be the
test condition for block:

    if (!context->keep_open) {
        ret =3D context->db->hdb_open(context->context, context->db, =
O_RDWR, 0);
        if(ret)
            return ret;
    }

So somehow the server_handle passed to change() is NULL.  Which
means that the kadm5_handle that kpasswdd passes to
kadm5_s_chpass_principal_cond() is NULL.  The handle is initialized via:

    ret =3D kadm5_init_with_password_ctx(context,
                                       admin,
                                       NULL,
                                       KADM5_ADMIN_SERVICE,
                                       &conf, 0, 0,
                                       &kadm5_handle);

And failure short-circuits the call to kadm5_s_chpass_principal_cond()
so it is not clear how this could happen.  Debugging symbols are needed.

--=20
	Viktor.