[20432] in Kerberos_V5_Development
Re: Parallel gss_get_mic or gss_wrap results in segfaults in
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Apr 27 14:06:05 2023
Date: Thu, 27 Apr 2023 13:04:18 -0500
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <ZEq5IiTE7gBh+1yi@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <24de0c82-2117-f28c-b0a5-8b662527a77d@mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Wed, Apr 19, 2023 at 01:52:52PM -0400, Greg Hudson wrote:
> The majority of the thread-safety work in the MIT krb5 libraries predates my
> tenure and it isn't fully documented, but it looks like there has never been
> a deliberate attempt to make GSS context handles safe when used
> simultaneously in multiple threads. In addition to the use of krb5_key
> objects which (deliberately) aren't internally locked, there is also
> mutation of the sequence numbers and sequence states. I think this hasn't
> come up before because most protocols using GSS message protection are
> inherently sequential, so it rarely makes sense to produce or process
> messages in parallel within a context. But the GSSAPI is intended to
> support non-sequential protocols, so there would be some value in making
> this work.
>
> Heimdal has internally locked context handles, and limits the critical
> section to sequence number handling. Adding a lock to the MIT krb5 context
> structure should be straightforward, but limiting the critical section would
> be harder due to the krb5_key type.
In OpenJDK 21 this will almost certainly cause crashes in Java apps
using the new green thread scheme.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
