[
https://issues.apache.org/jira/browse/DIRKRB-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Attila Sasvari updated DIRKRB-621:
----------------------------------
Attachment: DIRKRB-621-02.patch
Patch includes some logic for reposition (skipping over bytes) to the next
keytab entry in readEntries() of Keytab.
However, I double checked that the available() method of
[FileInputStream|https://docs.oracle.com/javase/8/docs/api/java/io/FileInputStream.html]
returns only an estimate.
[ByteArrayInputStream|https://docs.oracle.com/javase/8/docs/api/java/io/ByteArrayInputStream.html]'s
javadoc says
{quote}
Returns the number of remaining bytes that can be read (or skipped over) from
this input stream.
{quote}
so it might be more feasible.
Note: the implementation of
[KeytabDecoder|https://github.com/apache/directory-server/blob/trunk/kerberos-codec/src/main/java/org/apache/directory/server/kerberos/shared/keytab/KeytabDecoder.java#L76]
looks more defensive.
> 0x502 version keytab with multiple entries are not read properly
> ----------------------------------------------------------------
>
> Key: DIRKRB-621
> URL: https://issues.apache.org/jira/browse/DIRKRB-621
> Project: Directory Kerberos
> Issue Type: Bug
> Reporter: Attila Sasvari
> Attachments: DIRKRB-621-00.patch, DIRKRB-621-01.patch,
> DIRKRB-621-02.patch, test_multiple_entries.keytab
>
>
> I have a version 0x502 keytab that contains multiple principles with multiple
> entries.
> {code}
> [root@65027d995418 /]# klist -ket test.keytab
> Keytab name: FILE:test.keytab
> KVNO Timestamp Principal
> ---- -----------------
> --------------------------------------------------------
> 3 04/11/17 14:16:34 test/[email protected]
> (aes256-cts-hmac-sha1-96)
> 3 04/11/17 14:16:34 test/[email protected]
> (aes128-cts-hmac-sha1-96)
> 3 04/11/17 14:16:34 test/[email protected] (des3-cbc-sha1)
> 3 04/11/17 14:16:34 test/[email protected] (arcfour-hmac)
> 3 04/11/17 14:16:34 test/[email protected] (camellia256-cts-cmac)
> 3 04/11/17 14:16:34 test/[email protected] (camellia128-cts-cmac)
> 3 04/11/17 14:16:34 test/[email protected] (des-hmac-sha1)
> 3 04/11/17 14:16:34 test/[email protected] (des-cbc-md5)
> 3 04/11/17 14:16:51 HTTP/[email protected]
> (aes256-cts-hmac-sha1-96)
> 3 04/11/17 14:16:52 HTTP/[email protected]
> (aes128-cts-hmac-sha1-96)
> 3 04/11/17 14:16:52 HTTP/[email protected] (des3-cbc-sha1)
> 3 04/11/17 14:16:52 HTTP/[email protected] (arcfour-hmac)
> 3 04/11/17 14:16:52 HTTP/[email protected] (camellia256-cts-cmac)
> 3 04/11/17 14:16:52 HTTP/[email protected] (camellia128-cts-cmac)
> 3 04/11/17 14:16:52 HTTP/[email protected] (des-hmac-sha1)
> 3 04/11/17 14:16:52 HTTP/[email protected] (des-cbc-md5)
> {code}
> {{org.apache.kerby.kerberos.kerb.keytab.KeyTab}} readEntry() is only able to
> read the first entry properly.
> On
> https://web.mit.edu/kerberos/krb5-1.12/doc/formats/keytab_file_format.html,
> we can read the following:
> {quote}
> Some implementations of Kerberos recognize a 32-bit key version at the end
> of an entry, if the record length is at least 4 bytes longer than the entry
> and the value of those 32 bits is not 0. If present, this key version
> supersedes the 8-bit key version.
> {quote}
> Looking at
> https://www.gnu.org/software/shishi/manual/html_node/The-Keytab-Binary-File-Format.html,
> it seems {{uint32_t vno; /* only present if >= 4 bytes left in entry */}} is
> not handled in the
> [load()|https://github.com/apache/directory-kerby/blob/8483322e58310ff33685a1f3893b71e7cf5f246f/kerby-kerb/kerb-util/src/main/java/org/apache/kerby/kerberos/kerb/keytab/KeytabEntry.java#L40]
> method of {{org.apache.kerby.kerberos.kerb.keytab.KeytabEntry}}.
> With the example keytab I generated, this is exactly the case. We need to
> read an additional in order to properly read in the entries for the
> principals.
> Additional info:
> Kerberos packages I installed on centos-release-7-3
> {noformat}
> krb5-devel.x86_64 1.14.1-27.el7_3
> krb5-libs.x86_64 1.14.1-27.el7_3
> krb5-server.x86_64 1.14.1-27.el7_3
> krb5-workstation.x86_64 1.14.1-27.el7_3
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
