NegativeArraySizeException in JGSS / SASL

Weijun Wang weijun.wang at oracle.com
Sun Feb 10 15:39:52 UTC 2013


Hi Hugh

You can report a bug at http://bugs.sun.com/.

The problem seems to be at this line

 > FINE: KRB5CLNT07:Client max recv size: 65,536; server max recv size: 
0; rawSendSize: -69

where the server max recv size is 0. This is quite strange. I am 
thinking that a wrong packet is received.

Can you adjust the log level to FINER and send me the debug output? You 
can send it directly to me if you are afraid the mysterious hex data 
might contain anything sensitive.

Thanks
Weijun

On 02/10/2013 09:54 PM, Hugh Cole-Baker wrote:
> Hi there,
>
> I'm running into an exception when trying to communicate with an OpenLDAP server
> using SASL GSSAPI for authentication, with integrity and privacy protection
> (i.e. with the javax.security.sasl.qop property set to auth-conf).
>
> I think the problem may be related to the SASL client
> (com.sun.security.sasl.gsskerb.GssKrb5Client) negotiating a negative rawSendSize
> value which is then used as an array length. If I turn on FINE logging I see:
>
> com.sun.security.sasl.gsskerb.GssKrb5Client constructor
> FINE: SASLIMPL01:Preferred qop property: auth-conf
> com.sun.security.sasl.gsskerb.GssKrb5Client constructor
> FINE: SASLIMPL02:Preferred qop mask: 4
> com.sun.security.sasl.gsskerb.GssKrb5Client constructor
> FINE: SASLIMPL03:Preferred qops : 4 0 0
> com.sun.security.sasl.gsskerb.GssKrb5Client constructor
> FINE: SASLIMPL04:Preferred strength property: null
> com.sun.security.sasl.gsskerb.GssKrb5Client constructor
> FINE: SASLIMPL05:Cipher strengths: 4 2 1
> com.sun.security.sasl.gsskerb.GssKrb5Client <init>
> FINE: KRB5CLNT01:Requesting service name: ldap at dir-1.dev.local
> com.sun.security.sasl.gsskerb.GssKrb5Client doFinalHandshake
> FINE: KRB5CLNT06:Server protections: 7
> com.sun.security.sasl.gsskerb.GssKrb5Client doFinalHandshake
> FINE: KRB5CLNT07:Client max recv size: 65,536; server max recv size: 0; rawSendSize: -69
> com.sun.security.sasl.gsskerb.GssKrb5Client doFinalHandshake
> FINE: KRB5CLNT08:Selected protection: 4; privacy: true; integrity: true
> Exception in thread "main" java.lang.NegativeArraySizeException
> 	at sun.security.jgss.krb5.CipherHelper.aes256Encrypt(CipherHelper.java:1367)
> 	at sun.security.jgss.krb5.CipherHelper.encryptData(CipherHelper.java:722)
> 	at sun.security.jgss.krb5.WrapToken_v2.<init>(WrapToken_v2.java:200)
> 	at sun.security.jgss.krb5.Krb5Context.wrap(Krb5Context.java:861)
> 	at sun.security.jgss.GSSContextImpl.wrap(GSSContextImpl.java:385)
> 	at com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(GssKrb5Base.java:103)
> 	at com.sun.jndi.ldap.sasl.SaslOutputStream.write(SaslOutputStream.java:89)
> 	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:428)
> 	at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:547)
> (cut..)
>
> I've been able to cut down the test case to a simple program which logs in using
> JAAS to obtain a Kerberos ticket, then tries to connect to the LDAP server via
> JNDI, using GSSAPI for security, and tries to perform an LDAP search. With this
> test case I've been able to reproduce the bug on OpenJDK 7 on Ubuntu 12.04
> (package version 7u9-2.3.4-0ubuntu1.12.04.1) and Oracle's JDK for Mac 1.7.0_13.
> I have also tried the EA build of JDK 8 for Mac from Oracle
> (b76-macosx-x86_64-07_feb_2013) which shows the same problem.
>
> All the systems I've been testing on are part of a Kerberos realm with a MIT
> Kerberos KDC (v 1.10) and the JREs I've been testing have the unlimited-strength
> cryptography policies installed, which means they're able to use AES-256
> encryption types in Kerberos (apart from JDK 8 since I couldn't find a
> download for the policy files for that one).
>
> I'm not sure if this is a bug in OpenJDK or something to do with my test
> environment- I can attach the test case if necessary. If it is a bug in OpenJDK,
> what's the best place to report it? I checked on http://openjdk.java.net/ but
> couldn't find a link to a public bug tracker.
>
> Regards
> Hugh
>



More information about the security-dev mailing list