Summary
The parser and serializer only implement keytab file format version 2 (0x502). Version 1 (0x501) files are read with the wrong integer byte order, with an off-by-one component count, and with a non-existent name_type field, so version-1 keytabs are mis-parsed and cannot be produced.
Location
- File(s):
src/keytab/Keytab.go, src/keytab/KeytabEntry.go, src/keytab/KeyBlock.go, src/keytab/CountedOctetString.go
- Line(s) / function(s):
Keytab.FromBytes()/ToBytes(); KeytabEntry.FromBytes()/ToBytes(); KeyBlock.FromBytes()/ToBytes(); CountedOctetString.FromBytes()/ToBytes() — all hardcode binary.BigEndian and always read/write name_type.
Category
functional
Severity
medium
Version-1 keytabs (produced by older MIT/Heimdal tooling) are parsed into incorrect principals, key lengths, and encryption types, and the tool cannot emit version-1 output.
Reproduction / Evidence
Verified by code analysis against the MIT keytab file format specification. For format version 0x501 the spec defines three differences from 0x502, none of which the code implements:
- "Version 1 of the file format uses native byte order for integer representations" (version 2 always uses big-endian). All 16-bit and 32-bit integers — the record size, component count, counted-octet-string lengths, name_type, timestamp, encryption type, and kvno — are read/written with
binary.BigEndian unconditionally.
- The component count "includes realm in version 1", i.e. it is one greater than the number of name components; the code never subtracts 1, so it reads one component too many.
- The
name_type 32-bit field is "omitted in version 1"; the code always reads/writes 4 bytes for it, desynchronizing every subsequent field.
Expected Behavior
When FileFormatVersion is 0x501, integers are read/written in little-endian (native) order, the on-disk component count is the number of name components plus one, and the name_type field is absent (defaulting to the principal name type in memory). Version-1 files round-trip to identical bytes.
Actual Behavior
Version-1 files are parsed as if version 2: big-endian integers, no component-count adjustment, and a phantom 4-byte name_type, producing corrupted entries. Serialization can only emit version-2 layout.
Root Cause
The byte order and the version-specific presence of name_type and the component-count adjustment are not derived from FileFormatVersion; the byte order is hardcoded to big-endian throughout.
Summary
The parser and serializer only implement keytab file format version 2 (0x502). Version 1 (0x501) files are read with the wrong integer byte order, with an off-by-one component count, and with a non-existent name_type field, so version-1 keytabs are mis-parsed and cannot be produced.
Location
src/keytab/Keytab.go,src/keytab/KeytabEntry.go,src/keytab/KeyBlock.go,src/keytab/CountedOctetString.goKeytab.FromBytes()/ToBytes();KeytabEntry.FromBytes()/ToBytes();KeyBlock.FromBytes()/ToBytes();CountedOctetString.FromBytes()/ToBytes()— all hardcodebinary.BigEndianand always read/writename_type.Category
functionalSeverity
mediumVersion-1 keytabs (produced by older MIT/Heimdal tooling) are parsed into incorrect principals, key lengths, and encryption types, and the tool cannot emit version-1 output.
Reproduction / Evidence
Verified by code analysis against the MIT keytab file format specification. For format version
0x501the spec defines three differences from0x502, none of which the code implements:binary.BigEndianunconditionally.name_type32-bit field is "omitted in version 1"; the code always reads/writes 4 bytes for it, desynchronizing every subsequent field.Expected Behavior
When
FileFormatVersionis0x501, integers are read/written in little-endian (native) order, the on-disk component count is the number of name components plus one, and thename_typefield is absent (defaulting to the principal name type in memory). Version-1 files round-trip to identical bytes.Actual Behavior
Version-1 files are parsed as if version 2: big-endian integers, no component-count adjustment, and a phantom 4-byte name_type, producing corrupted entries. Serialization can only emit version-2 layout.
Root Cause
The byte order and the version-specific presence of
name_typeand the component-count adjustment are not derived fromFileFormatVersion; the byte order is hardcoded to big-endian throughout.