Kerberos Bug Introduced in d777e2918a77?

Weijun Wang weijun.wang at oracle.com
Thu Apr 23 00:58:21 UTC 2015


Hi Daniel

I've read more about your bug report and know what's happening.

You are proposing 2 OIDs, [1.2.840.48018.1.2.2, 1.2.840.113554.1.2.2], 
1st one being Microsoft's own krb5 OID and 2nd the standard one. Java 
only understands the 2nd one but before that changeset it blindly 
accepts the mechToken without looking at the OID. Since it's also krb5, 
the mechToken is processed correctly and everything goes on. After the 
changeset, it does not recognize the OID anymore and asks the client to 
send another mechToken with 1.2.840.113554.1.2.2.

I believe a lot of people is using the Microsoft OID. I will see if it's 
possible to recognize both OIDs.

On the other hand, your program has

    context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length);
    String user = context.getSrcName().toString();

which is not standard. The acceptSecContext call should be in a loop 
until a context is established, and then you can call getSrcName(). Can 
you try that? Hopefully after the client sees the server request for a 
1.2.840.113554.1.2.2 mechToken it can send one and the server can go on.

Thanks
Max

On 4/23/2015 7:22 AM, Weijun Wang wrote:
> Hi Daniel
>
> Thanks for the report.
>
> In fact, the bug behind the changeset you mentioned -- 8048194 -- was
> just meant to make your case work. Before that, the server blindly
> accepts the mechToken and process it no matter if the OID is supported.
> Now it first looks at the OID and accept the token if it supports the
> OID; otherwise, only the negotiated result (its supported OID) is sent
> back, and waits for the client sending the correct mechToken in the next
> round.
>
> It seems the logic above is not implemented correctly, can you show me
> the full stack of your NullPointerException? If it includes any
> sensitive info you can write me privately.
>
> Thanks
> Max
>
> On 4/23/2015 12:21 AM, Rob McKenna wrote:
>> Hi Daniel,
>>
>> Thanks for the report, I'm cc'ing the security-dev alias.
>>
>>      -Rob
>>
>> On 22/04/15 13:10, Daniel Jones wrote:
>>> Hi all,
>>>
>>> Apologies if this is the wrong mailing list - please direct me to the
>>> correct one if so.
>>>
>>> I believe I've found a bug in OpenJDK 1.8.0_40, introduced in commit
>>> d777e2918a77:
>>> http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
>>>
>>>
>>>
>>> The change introduced on line 548 means that an authentication
>>> mechanism is
>>> only accepted if the OID of the mechanism desired is the *first* in the
>>> list of mechanisms specified as acceptable in the incoming ticket.
>>>
>>> In the case of my current client their service tickets are specifying 4
>>> acceptable mechanism OIDs, but the only available mechanism's OID
>>> appears
>>> second on that list. So whilst the server *can *satisfy the ticket, the
>>> code change on line 548 prevents this from happening.
>>>
>>> Using the same server code, the same Kerberos KDC, and OpenJDK 1.8.0_31,
>>> everything works. Changing only the JDK results in the mechContext not
>>> being properly populated, which in turn causes a NullPointerException
>>> from
>>> some Spring Security Kerberos code.
>>>
>>> Has anyone else experienced this?
>>>
>>>
>>


More information about the security-dev mailing list