Recent changes to bugs

#62 Fails to build with MIT Kerberos 1.18

Joakim Tjernlund — Tue, 02 Mar 2021 17:44:23 -0000

I replaced the patch in ticket #61 with this instead(quite some time ago):
```
--- ./src/mod_auth_kerb.c.org 2020-08-13 17:30:15.901691505 +0200
+++ ./src/mod_auth_kerb.c 2020-08-13 17:35:00.069621299 +0200
@@ -2062,6 +2062,11 @@
static int
have_rcache_type(const char type)
{
+ / rcache "none" is always present in modern mit-krb5
+ * but krb5_rc_resolve_full() has been removed in 1.18.x
+ * so hardcode to true */
+ return 1;
+#if 0
krb5_error_code ret;
krb5_context context;
krb5_rcache id = NULL;
@@ -2079,6 +2084,7 @@
krb5_free_context(context);

return found;

+#endif
}

/***********

Fails to build with MIT Kerberos 1.18

Sam Hartman — Fri, 20 Nov 2020 20:17:23 -0000

If you take a look at src/mit-internals.h you'll see that the code copies internals from MIT Kerberos 1.3 to try and disable the replay cache. Unfortunately, the replay cache was refactored in ersion 1.18, and these internals no longer build. There's a "fix" to this in ticket 61, but that fix introduces a memory leak and replaces one set of internals with another. At this point I am fairly sure that the actual default replay cache should work, even against Microsoft authenticators, so we could simply remove the internals completely and use the default replay cache.
It might be better to disable things. That can be done with a setenv call, but that's undesirable in a apache module. I'm not remembering off the top of my head whether there's a better way to do this at the gss layer.

#61 Use after free in authenticate_user_krb5pwd()

Joakim Tjernlund — Wed, 12 Aug 2020 16:00:14 -0000

This makes mod_auth_kerb load when built against mit-krb5-1.18.2
Not run tested yet

#61 Use after free in authenticate_user_krb5pwd()

Paul Wise — Mon, 21 Oct 2019 03:49:20 -0000

FYI I've just added this patch to the Debian package of mod_auth_kerb in response to Debian bug #934043.

Use after free in authenticate_user_krb5pwd()

Johan Ymerson — Thu, 13 Dec 2018 08:59:26 -0000

In verify_krb5_user() krb5_kt_close() is called under certain conditions, but krb5_kt_close() is also called from the top level function authenticate_user_krb5pwd() after calling verify_krb5_user().
This leads to a use after free, since kbr5_kt_close() free up memory pointed to in the keytab struct and
the next call to krb5_kt_close() will dereference pointers in that (now freed) memory.
This leads to a segmentation fault with recent versions of MIT Kerberos.

Patch to fix this attached.

#60 Strim REALM\ in username

chris — Wed, 23 Nov 2016 17:06:38 -0000

Looks like this should be done somewhere in function authenticate_user_krb5pwd, where also the '@' character is searched in the auth line

Strim REALM\ in username

chris — Wed, 23 Nov 2016 16:59:29 -0000

Hi,
This is quite similar to [#42]. Citrix sends the user name as "REALM\username", and mod_auth_krb then tries to authenticate the username "REALMusername".
Can this be fixed as in [#42]?
Thanks

Login fails if Password contains § Symbol

Thomas Braun — Fri, 05 Jun 2015 10:28:25 -0000

krb5_get_init_creds_password() failed: Invalid argument

KrbSaveCredentials + KeepAlive = poof

Dorian Taylor — Mon, 01 Apr 2013 06:29:16 -0000

I know my way around Apache modules, but I'm an initiate to mod_auth_kerb, and I've noticed that when I refresh my test CGI too frequently, the credential cache disappears. This doesn't happen, however, if I set KeepAlive off.

I understand that Kerberos operates at the connection level, so it seems as if it would be possible to authenticate on the first request and then keep that connection authenticated until it disconnected, at which point the credential cache could be removed. This behaviour would gracefully degrade to Connection: close.

I'd be happy to hack on it if somebody would show me around.

Crash on graceful Apache reload

Dustin C. Hatch — Fri, 28 Dec 2012 02:07:51 -0000

After upgrading to Apache 2.2.23 recently, I found that initiating a graceful reload of a running Apache process (i.e. /etc/init.d/apache2 reload) would cause Apache to crash. By turning on debug logging, I was able to find this message, indicating that the problem was caused by mod_auth_kerb:

apache2: threads.c:351: krb5int_key_register: Assertion `destructors_set[keynum] == 0' failed.
[Thu Dec 27 20:04:58 2012] [notice] seg fault or similar nasty error detected in the parent process

Please let me know if there is a way I can provide additional information in order to help you track down this problem.