GSSAPI Key Exchange Patch
rapier at psc.edu
Tue Nov 20 02:36:35 EST 2007
Simon Wilkinson wrote:
> On 16 Nov 2007, at 08:25, Damien Miller wrote:
>> Yes - we are very scared of adding features that lead to more
>> pre-authentication attack surface, especially when they delegate to
>> complex libraries with patchy security histories.
> I'm not convinced that adding key-exchange actually increases the pre-
> authentication attack surface. At the end of the day the same
> payloads are getting passed through to the same privileged process
> (and onwards to the same complex library) as happens when doing
> GSSAPI user authentication. The only difference is that one happens
> after the key exchange step has been performed, and the other happens
> as part of it.
Part of the problem, at least as far as I can see is it, is maintaining
any patch that is incorporated. Any time something like this is included
there is the strong possibility that the responsibility for keeping the
included features up to date will fall onto the shoulders of an already
overworked development team. Even if it's just included as a compile
time option this can become a bit of a burden.
The more integral the patch is to a critical aspect of the code base the
more likely this becomes. That being said, I've occasionally wondered if
there is a solution for all of this that would make things easier for
the end users without overwhelming the developers. Perhaps a
pre-configure utility that can be used to fetch well known patches from
a maintained canonical repository and automagically incorporate them.
Obviously, that can be problematic in its own right (conflicting
patches, who maintains the patch repository, what gets included, etc).
More information about the openssh-unix-dev