Creating a new pre-authentication plugin
ghudson at MIT.EDU
Wed Aug 1 16:09:44 EDT 2012
On 08/01/2012 03:03 PM, Alejandro Perez Mendez wrote:
>> Accepting pointer values from
>> the client would open up the KDC to memory attacks.
> Again, that's a matter of implementation.
Yes, but we know what our implementation is, and it uses pointer values.
> Anyway, IMO that kind of memory attacks (i.e. context does not exists)
> SHOULD be handled at a GSS-API level.
As far as I'm aware, there's no good way to do this in a library GSSAPI
implementation. Back before we had a mechglue, we used to have a table
of valid pointer values, but that required global synchronization for
every GSSAPI call.
>> The KDC would also need some way to release abandoned GSSAPI handles.
> Yes, this would be the more problematic issue. I need to figure out how
> to solve this. But, just asking, isn't it a problem that GSS-API
> implementation has to deal with?
No, or there wouldn't need to be gss_release_ functions.
>> Second, sending two requests on the same UDP socket does not guarantee
>> that the same KDC process handles them. There could be multiple worker
>> processes serving the same socket (see the man page documentation of
>> krb5kdc -w), or there could be a network element (like an F5)
>> distributing requests on the same IP and port to different real KDC
> Again, just asking, wouldn't these workers share the same GSS-API memory
> space? Wouldn't mech_glue be the same for all of them?
No, in both cases. KDC worker processes have distinct address spaces,
and of course if a network element is distributing requests to different
real KDC hosts, they will have distinct address spaces by virtue of
being on different machines.
More information about the krbdev