Skip to content

Version 1 (0x501) keytab files are mis-parsed: wrong byte order, component count, and name_type handling #5

Description

@p0dalirius

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:

  1. "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.
  2. 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.
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions