svn rev #23611: trunk/src/lib/crypto/crypto_tests/
epeisach at mit.edu
Fri Jan 8 11:17:29 EST 2010
I love replying to myself...
Anyways - I have trapped enctype = 0 i the key freeing code and can say
except for the kdc fast code handling - in which enctype = 0 and length
= 0 (which is ENCTYPE_NULL) - the tree runs now w/o enctype problems.
So - I believe that unless someone is setting up a krb5_keyblock
manually - everything is consistent.
On 01/08/2010 07:59 AM, Ezra Peisach wrote:
> I spoke too soon...
> I added an assertion in the free code to see if enctype was 0... Get
> hit in a number of programs... The kdc in verify_checksum from the
> kdc_find_fast. I think it using an empty krb5_keyblock - with zero
> length - so in theory
> who cares about the encryption type...
> I also found another problem in krb5int_dk_string_to_key creating a
> key w/o enctype - but that will be fixed soon...
> Ezra Peisach wrote:
>> The places that I have seen problems with have to deal with
>> a) crypto test programs
>> b) internal crypto functions - yarrow and derive key
>> In both cases it is because we know what is happening under the hood.
>> The (b) issues are easy fixes - the derive key problem was reported
>> by Doug in 2001 (ticket 959) and the other is because we are using
>> internal functions w/o full initialization.
>> The problem will manifest itself in one of two ways... The easy to
>> track down one is that valgrind will report a conditional jump based
>> on an uninitialized variable. However, if someone initializes the
>> enctype to 0 - using the aes internal encryption code - will result
>> in a memory leak. I know that the test programs in the crypto
>> libraries do not leak memory as I have fixed those over the years -
>> so when leaks showed up in test-aes it was obvious.
>> That said, I have run the test suite under valgrind - and right now
>> (from what I can see) is that the only complaints about conditional
>> jumps on uninitialized values is in the ssl code from the pkinit
>> preauth plugin. (I do not know if this is a problem w/ the plugin or
>> the ssl library). This however produces a large amount of noise in
>> the tests that I might have missed something. I also cannot tell if
>> there are problems w/ an enctype = 0 leaking memory.
>> I believe however, that external interfaces to the crypto library do
>> require a valid enctype - and this should be fine - unless
>> someone has cheated somewhere else.
>> Ken Raeburn wrote:
>>> On Jan 7, 2010, at 22:43, epeisach at MIT.EDU wrote:
>>>> The key caching is causing memory leaks if enctype is not set as the
>>>> enctype specific cleanup handlers are not called.
>>> Are there likely to be many cases outside of enctype-specific test
>>> programs where this shows up? If so, perhaps we (I?) should make
>>> the caching dependent somehow on having a suitable enctype value
>>> set. But currently that level of the code doesn't need to know
>>> about Kerberos enctype number assignments...
>>> krbdev mailing list krbdev at mit.edu
>> krbdev mailing list krbdev at mit.edu
More information about the krbdev