[1338] in Kerberos-V5-bugs
Re: Possible protocol change found in Krb5 Beta 4 flags encoding.
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Apr 18 20:45:55 1995
Date: Tue, 18 Apr 1995 20:45:40 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: "John J. Marco" <johnma@sco.COM>
Cc: krb5-bugs@MIT.EDU, dceivers@sco.COM, johnma@sco.COM
In-Reply-To: John J. Marco's message of Fri, 14 Apr 1995 17:27:04 -0700 (PDT),
<9504141727.aa02140@lubyanka.pdev.sco.COM>
From: "John J. Marco" <johnma@sco.COM>
Date: Fri, 14 Apr 1995 17:27:04 -0700 (PDT)
The change:
-----------
I looked at the code for two ASN.1 compiler based releases:
The OSF/DCE Kerberos code, based on the DCE Mavros compiler
The MIT V5 Beta4 ISODE/Pepsy based asn.1 code (now obsolete).
Both of the above implementations __Reverse__ the bit order of KRB5 flags
fields before passing them down the the ASN.1 encoder. This is done in
the following source files:
MIT/ISODE based: src/lib/krb5/asn.1/cvt_flags.c
OSF/DCE mavros: src/security/krb5/lib/mvr/krb5-manual-glue.c
The relevant thing to look for is the "swbits" array, used as a function
to reverse the bit order in a byte.
The MIT Krb5 Beta4 hand-coded asn.1 encoder does not appear to have any
code in it to reverse the bit order.
You are correct; this is a bug in the the hand-coded encoder and
decoder. The bug was caused by one of original implementers, who
believed that, bit 0 should be the msb, and encoded the bit fields in
the fieldbits.h include file that way. This has several problems,
including the fact that it's not terribly portable to non-32 bit
architectures, and it's exactly opposite to what the ASN.1 code demands.
When we did the hand-coded encoder, we missed this little curve ball
which said original implementer left behind for us, so we ommitted the
bit reversal.
The right way of fixing this is to reverse the bits in the fieldbits.h
file, so the bit reversal is no longer necessary. The fact that we
needed to do the bit reversal at all was fundamentally broken part in
the original code. (This should explain your confusion about why the
bit reversal was being done; it was through our own bone-headedness.
It's quite correct that that ASN.1 doesn't require the bit reversal.)
We can fix the interoperability problem to a small degree by causing the
decoder to check to see if the high 16 bits are set, and if so, doing a
bit reversal. This will fix the rlogin program in that a new server
will be able to accept connections from either old or new clients.
Unfortunately, since the TicketFlags bit string is communicated to the
client and stored in the ticket cache, it will be difficult if not
impossible to completely fix the interoperability problem in that case.
Thank you very much for calling this serious problem to my attention!!
Fortunately, most of the Kerberos code that is being shipped by vendors,
do not, as far as I know, have this problem; we caught this problem
before most vendors had a chance to incorporate this code in their
products. May I forward your message to krb5-bugs to the Kerberos
mailing list, along with my response? I believe it is important that
everyone know about this problem as soon as possible. (With any luck, I
will also include some patches which will help ameliorate the
interoperability problems.)
- Ted
