From 1ab27b7fdf0e25636a2b9cc933ee17ded60ad948 Mon Sep 17 00:00:00 2001 From: Andrew Bartlett Date: Wed, 2 Nov 2005 09:51:32 +0000 Subject: r11477: This seems really nasty, but as I understand it an attacker cannot change this checksum, as it is inside the encrypted packets. Where the client (such as Samba3) fakes up GSSAPI, allow it to continue. We can't rid the world of all Samba3 and similar clients... Andrew Bartlett (This used to be commit e60cdb63fb37e44252f83a56a6302f0bd22dec4d) --- source4/heimdal/lib/gssapi/8003.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) (limited to 'source4/heimdal/lib') diff --git a/source4/heimdal/lib/gssapi/8003.c b/source4/heimdal/lib/gssapi/8003.c index b60d2608e2..0062068d5b 100644 --- a/source4/heimdal/lib/gssapi/8003.c +++ b/source4/heimdal/lib/gssapi/8003.c @@ -182,9 +182,18 @@ gssapi_krb5_verify_8003_checksum( *minor_status = 0; return GSS_S_BAD_BINDINGS; } - + + /* This is the case where Samba3 has built GSSAPI out of + * krb5 the 'dodgy' way. We have to accept the non-GSSAPI + * checksum because windows does */ + + if(cksum->cksumtype != CKSUMTYPE_GSSAPI) { + *flags = 0; + return GSS_S_COMPLETE; + } + /* XXX should handle checksums > 24 bytes */ - if(cksum->cksumtype != CKSUMTYPE_GSSAPI || cksum->checksum.length < 24) { + if(cksum->checksum.length < 24) { *minor_status = 0; return GSS_S_BAD_BINDINGS; } -- cgit