general protection fault in libpam-heimdal/sshd

[Steven McCoy]

Binary package hint: libpam-heimdal

Ubuntu 8.04 _only_ on AMD64, i386 is _not affected_. SSHD crashes refusing client access with the following common-auth:

auth sufficient pam_krb5.so ccache=/tmp/krb5cc_%u
auth sufficient pam_unix.so likeauth nullok_secure use_first_pass
auth required pam_deny.so

That's the Heimdal version of pam_krb5.so. Swapping the lines around makes the login work, with the crash only appearing on invalid login attempts.

auth sufficient pam_unix.so likeauth nullok_secure
auth sufficient pam_krb5.so ccache=/tmp/krb5cc_%u use_first_pass
auth required pam_deny.so

[AdamTNRG (adam-myers)]

We are also seeing this problem at our organization. The machine in question is an AMD64 running the AMD64 server install of Ubuntu 8.04.

We have other machines that are AMD64 based but running the i386 server install without problems.

The above re-ordering of common-auth does not work around the problem in our environment, sshd still segfaults.

[Chris (chris-hoypoy)]

I have the same problem on a bank of AMD64 systems, and an Intel SMP system running AMD64 Kubuntu 8.04.1 (kde4).

With the reordered common-auth, problem occurs only on invalid login (as stated by StevenMcCoy)

They appear to occur as soon as OpenSSH gets the "Unknown User" or invalid request from kerberos (according to my KDC logs).

[kryanth (chris-gopc)]

I'm seeing issues where some SSH clients seem to provoke this problem in a different order (ie triggering the failure) - this supports AdamTNRG's report that sshd segfaults all the time for his setup.

[kryanth (chris-gopc)]

In an attempt to poke around this issue, I recompiled sshd from ubuntu source, and the problem doesn't occur.

I configured it with :
./configure --with-pam --with-kerberos5=/usr --with-md5-passwords --with-tcp-wrappers --prefix=/usr --sysconfdir=/etc/ssh

I'll probably need to work out the original Ubuntu compile options in order to compare correctly. I havent introduced any other non-ubuntu source packages to this system

only other related dev packages (I believe).
ii heimdal-dev 1.0.1-5ubuntu4 Heimdal Kerberos - development files
ii libpam0g-dev 0.99.7.1-5ubun Development files for PAM
ii libssl-dev 0.9.8g-4ubuntu SSL development libraries, header files and

[kryanth (chris-gopc)]

spoke too soon..
newly compiled ssh lets me in, but doesnt actually accept kerberos-passthrough, so its broken if you require that.

[kryanth (chris-gopc)]

I have this chased down to the following line:

Line 256 in support.c

retval = krb5_get_init_creds_password(ctx->context,
                          &creds, ctx->princ, pass, pamk5_prompter_krb5,
                          ctx->pamh, 0, in_tkt_service, &opts);

I believe the krb5_get_init_creds_password call is returning some invalid code ( -1765328360 doesnt sound like a realistic retval considering the other values )

This then gets passed to krb5_compat_get_err_text at logging.c [81]

which ultimately passes it off to heimdal codes (where I lose the plot on tracking it)
compat_heimdal.c[26]
     23 const char *
     24 pamk5_compat_get_err_text(krb5_context c, krb5_error_code code)
     25 {
     26 return krb5_get_err_text(c, code);
     27 }

Which produces the segfault (presumably because it doesnt like the value passed).

Now to go find someone who knows the heimdal stuff enough to point me in the right direction there...

In the meantime, I've cheated and masked the problem by swapping retval for what appears to be a valid error code. Thats a cheap hack, but I need it to not segfault right now :P

[kryanth (chris-gopc)]

On further investigation..
the error code ( -1765328360 ) is valid but the heimdal libraries don't seem to be able to return the correct error code from it.

(that error code is correct for an authentication failure.

My C skills are are bit out of whack for this :) 64bit longs vs. the int32_t definition in the heimdal libs perhaps?

someone with more recent C experience will probably pick this out easier, or just backport the 3.10 libraries from Intrepid for Hardy.

[ooboyle (oliver-oboyle)]

I too have this problem. AMD64 as a VM on a VMware ESX server.

This doesn't happen with the libpam-krb5 version, only the libpam-heimdal version.

Any news on soon a fix will be available? I'm about to scrap a project if it won't be soon.

Regards,
Oliver

[ooboyle (oliver-oboyle)]

Iif it's any help, I have one VM that doesn't segfault, but it gives me an access denied error on all ssh logon attempts.

1) The ssh session gets established with default settings,
2) I'm prompted for a username,
3) prompted for a password,
4) then given an Access Denied error.

I've tried from many different ssh clients and it's consistent.

The only difference between this VM and the ones that segfault is that this VM was initially isntalled with krb5-user and libpam-krb5, was working in this config, then I removed them and installed heimdal-users and ibpam-heimdal.

Oliver

[ooboyle (oliver-oboyle)]

I meant heimdal-clients... and libpam-heimdal. sorry for the typos.

[ooboyle (oliver-oboyle)]

Update:

After some more investigation, I got it to work in a specific situation. SSH will not segfault and it will not produce an Access Denied message if the following is true:

1) An /etc/krb5.conf file exists with a "default_realm = <yourrealmname>" entry in the [libdefaults] section.
2) There is no "pam {<youroptions>}" in the [appdefaults] section of the /etc/krb5.conf file.

Observations:

a) The mere existence of a "pam {<youroptions>}" entry in /etc/krb5.conf causes the segfault.
b) The lack of any /etc/krb5.conf file causes the Access Denied message.

Without an /etc/krb5.conf file, Heimdal Kerberos is supposed to be able to glean this information from DNS if it exists. As such, in an Active Directory environment, there should be no issues here because the necessary information is always available. To make extra sure, I added a _kerberos TXT record pointing to my realm because this isn't normally visible in MS DNS by default. This made no difference.

It's still not clear to me why an explicit mention of the default realm is required in the krb5.conf file when this information is available via DNS. Perhaps someone else has an idea?

Oliver

[ooboyle (oliver-oboyle)]

Update:

To workaround the bug WITHOUT the need for a krb5.conf file, you can also add a "realm=<YOURREALM>" option in PAM's common-auth file. As the man pages suggest, you should set this option for all groups (e.g. common-session, common-account, common-password, common-auth) even though the common-account group doesn't care about realm.

I guess this points to PAM not being able to find the default realm on its own.

Oliver