[20286] in Kerberos_V5_Development
Re: Thread safety issue in krb5_verify_init_creds() when passing
daemon@ATHENA.MIT.EDU (Thomas Sondergaard)
Mon May 31 11:35:18 2021
MIME-Version: 1.0
In-Reply-To: <d757ebc7-5d7e-e826-9e40-45972328fa32@mit.edu>
From: Thomas Sondergaard <thomas@sondergaard.cc>
Date: Mon, 31 May 2021 17:34:57 +0200
Message-ID: <CAKxQmMtKjbnTCn6F_NEF-P8dk15CMscEnodHmtf_bqJ829qBvA@mail.gmail.com>
To: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Fri, May 28, 2021 at 6:31 PM Greg Hudson <ghudson@mit.edu> wrote:
>
> On 5/28/21 5:14 AM, Thomas Sondergaard wrote:
> > It calls krb5_parse_name to create a principal from princ_name and then
> > krb5_get_init_creds_passwords to create a krb5_creds. It then calls
> > krb5_verify_init_creds(). If that checks out it then calls
> > krb5_cc_get_principal to dig the principal out of the returned
krb5_ccache
> > and then calls krb5_unparse_name and returns that to the caller. Is
there
> > any situation where this returned principal will be different from the
one
> > the caller of the function provided?
>
> There isn't. The returned ccache is initialized with creds->client
> (vfy_increds.c:162), so reading its principal will just give that back
> again.
Excellent. That makes the bug irrelevant for me, as I am now just calling
krb5_get_init_creds_password() with a null pointer for ccache.
>
> >> With what version of the krb5 libraries? The issue you identified
below
> >> is a concern, but a crash indicates a problem in the ccache layer.
> >> Ticket #8202 (fixed in 1.17) addresses a bug that could explain the
crash.
> >>
> >
> > It is on CentOS 8.3.2011 with krb5-libs-1.18.2-5.el8.x86_64
>
> In that case, if you have the ability to get a stack trace for the
> crash, I'd be interested in seeing it.
For the next 80-90 days you can use this link:
https://sentry.io/share/issue/abfd015151f2493898af980fc94bee79/ where you
can see the stacktrace of the crashing thread and all the other threads.
The crashing thread itself has this stack. I don't think it is that
helpful. My function getDefaultPrincipal() calls krb5_cc_get_principal()
followed by krb5_unparse_name() to get the string representation of the
default principal.
PosixSignal: Signal 11 in node
File "<unknown>", in __memmove_sse2_unaligned_erms
File "/usr/include/bits/string_fortified.h", line 34, in memcpy
File
"/usr/src/debug/krb5-1.18.2-5.el8.x86_64/src/lib/krb5/krb/copy_data.c",
line 93, in krb5int_copy_data_contents_add0
File
"/usr/src/debug/krb5-1.18.2-5.el8.x86_64/src/lib/krb5/krb/copy_princ.c",
line 63, in krb5_copy_principal
File "<unknown>", in getDefaultPrincipal[abi:cxx11]
File "<unknown>", in verifyCredentials
File "<unknown>", in std::_Function_handler<T>::_M_invoke
File "<unknown>", in SimplePromiseWorker::Execute
File "<unknown>", in Napi::AsyncWorker::OnExecute
File "/home/iojs/build/ws/out/../deps/uv/src/threadpool.c", line 122, in
worker
File "<unknown>", in start_thread
File "<unknown>", in clone
Best regards,
Thomas
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
