[16560] in Kerberos-V5-bugs
[krbdev.mit.edu #8914] Invalid negative record length in keytab file
daemon@ATHENA.MIT.EDU (Joshua Neuheisel via RT)
Fri Jun 12 16:32:57 2020
From: "Joshua Neuheisel via RT" <rt-comment@krbdev.mit.edu>
In-Reply-To: <07C4B3B3-2D0B-4299-B6D5-7A370FC6736D@stsci.edu>
Message-ID: <rt-4.4.4-127831-1591993948-923.8914-4-0@mit.edu>
To: "AdminCc of krbdev.mit.edu Ticket #8914":;
Date: Fri, 12 Jun 2020 16:32:29 -0400
MIME-Version: 1.0
Reply-To: rt-comment@krbdev.mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krb5-bugs-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Fri Jun 12 16:32:28 2020: Request 8914 was acted upon.
Transaction: Ticket created by jneuheisel@stsci.edu
Queue: krb5
Subject: Invalid negative record length in keytab file
Owner: Nobody
Requestors: jneuheisel@stsci.edu
Status: new
Ticket <URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8914 >
I’ve found an unlikely case where keytab record lengths produce unexpected behavior. The following snippet of code, when run in bash, will create a 2GB file called bad.keytab. When this file is read (read_kt) using ktutil, the process will enter an infinite loop:
(echo -ne '\05\02\0200\0\0\010'; dd if=/dev/zero count=21474 bs=100000; dd if=/dev/zero count=1 bs=83640; echo -ne '\0200\0\0\0') >bad.keytab
The reason is the code in krb5_ktfileint_internal_read_entry (kt_file.c:924 in krb5-1.18.2.tar.gz) assumes that the 2s compliment of a negative 32bit integer is always positive. This is not true for (int32_t) 0x80000000.
Given the wording of https://web.mit.edu/kerberos/krb5-1.18/doc/formats/keytab_file_format.html, it’s not clear to me what the expected behavior should be, although an infinite loop is definitely undesirable. I’d be happy to help supply a patch if it’s clear what the expected behavior should be.
Thanks,
Joshua Neuheisel
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
