Not sure we handled this one : CAN-2005-2798 =========================================================== An information disclosure vulnerability has been found in the SSH server. When the GSSAPIAuthentication option was enabled, the SSH server could send GSSAPI credentials even to users who attempted to log in with a method other than GSSAPI. This could inadvertently expose these credentials to an untrusted user.
This is fixed in 4.2, see the release notes : - SECURITY: sshd in OpenSSH versions prior to 4.2 allow GSSAPI credentials to be delegated to users who log in with methods other than GSSAPI authentication (e.g. public key) when the client requests it. This behaviour has been changed in OpenSSH 4.2 to only delegate credentials to users who authenticate using the GSSAPI method. This eliminates the risk of credentials being inadvertently exposed to an untrusted user/host (though users should not activate GSSAPIDelegateCredentials to begin with when the remote user or host is untrusted) Can we mark 4.2 stable or is it too soon ?
i'm not aware of any open issues that exist in openssh-4.2_p1 that dont already exist in the current stable so afaict, moving to 4.2_p1 should be safe
ok then, lets do it, target is 4.2_p1 Target KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sh sparc x86"
Marked ppc64 stable
x86 done
Stable on ppc and hppa.
Stable on mips.
amd64 stable
SPARC'd
Stable on alpha + ia64.
This one is ready for GLSA vote. I tend to vote yes.
"users should not activate GSSAPIDelegateCredentials to begin with when the remote user or host is untrusted" --> I tend to vote no.
stable on sh
Agree with koon, vote NO.
I'd say no here
Closing then
did any other distro send out notification ?
SpanKY: most of them did. Ubuntu USN-208-1 Mandrake MDKSA-2005:172 redHat RHSA-2005:527-01 Feel free to reopen if you disagree, if possible explaining how the GSSAPIDelegateCredentials works, maybe it's more serious than we think...
