[11681] in Kerberos-V5-bugs
[krbdev.mit.edu #6770] kg_unseal leads to overlap of source and
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Mon Sep 13 20:31:41 2010
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Greg Hudson via RT" <rt-comment@krbdev.MIT.EDU>
In-Reply-To: <rt-6770@krbdev.mit.edu>
Message-ID: <rt-6770-33132.16.3706184407346@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #6770'":;"'AdminCc of krbdev.mit.edu Ticket #6770'":;@MIT.EDU
Date: Mon, 13 Sep 2010 20:31:39 -0400 (EDT)
Reply-To: rt-comment@krbdev.MIT.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
Mulling this one over still.
It's very unusual for callers to call krb5_[ck]_encrypt like this, since
normally the output needs a larger buffer than the input. In this use
case, the enctype is raw-mode DES, so in-place encryption is sensical.
There are four kg_encrypt call sites like this in the krb5 mech.
Possible solutions are:
1. Declare the callers at fault and change them. This would be fairly
easy since the encryptions are of fixed-length (16-byte) buffers.
2. Use memmove instead of memcpy, or check if input->data == output-
>ciphertext.data + header_len and elide the memcpy in that case. This
would allow aliasing of input and output in krb5_k_encrypt only for raw-
mode enctypes.
3. Allow aliasing for all enctypes somehow. (I'm not sure if it worked
for non-raw enctypes prior to 1.8.)
I am currently tempted to go with #1 since the other solutions have a
performance impact on well-behaved callers.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
