Kerberos Bug Introduced in d777e2918a77?

Thu Apr 23 13:51:47 UTC 2015

Hi all,

FYI We just tried switching to Oracle JRE u45, and the same behaviour is
exhibited there.

This is a bit of a problem for my client, as they can't use Java and
Kerberos whilst still being able to satisfy their security department's
policy regarding zero-day bugs. If a new patch gets released for a security
issue, we won't be able to adopt it.

On Thu, Apr 23, 2015 at 12:25 PM, Daniel Jones <
daniel.jones at engineerbetter.com> wrote:

> Hi all,
>
> Thanks to everyone taking the time to look into this.
>
> Before I get into the detail of the technical issue, can anyone postulate
> as to *how quickly fixes tend to make it into releases of OpenJDK*? Are
> we talking days, weeks, or months? I'm just trying to advise my client on
> the best mitigation strategy until the issue is resolved.
>
> The Spring code in question actually changed this morning to throw a more
> useful error:
> https://github.com/spring-projects/spring-security-kerberos/commit/f046bd7c69d6dad74eb06a7651cd68060b31ff6f
>
> 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().
>
>
> I'm not sure that this would work. I'm not at all familiar with what is
> best practice in handling Kerberos tickets, but let me explain what happens
> at present in u40:
>
>
>    1. Spring's SunJaasKerberosTicketValidator gets a GSSContextImpl, and
>    calls acceptSecContext on it.
>    2. The GSSContextImpl calls an overloaded accetSecContext method,
>    which successfully creates a SpNegoContext and assigns it as the mechCtxt
>    member.
>    3. GSSContextImpl#acceptSecContext then calls
>    SpNegoContext#acceptSecContext
>    4. In SpNegoContext#acceptSecContext we have the new functionality
>    that only looks at the top item of the list of OIDs from the service
>    ticket.
>    5. The inner mechContext of the SpNegoContext is not set.
>    6. We return back to the Spring code, with a GSSContextImpl wrapping a
>    SpNegoContext
>    7. Spring calls GSSContextImpl#getSrcName(), which delegates to
>    SpNegoContext#getSrcName(), which returns null as its mechContext member is
>    null.
>
>
> Spring passes the whole ticket into GSSContextImpl, and doesn't know about
> OIDs and the list of acceptable mechanisms. It seems like it's a
> responsibility of either SpNegoContext or GSSContextImpl to know about this
> list and iterate over it.
>
> If the Spring code were to attempt a repeat, how should it know that the
> inner context was not set? What action should it perform next? It's passed
> in the ticket it knows about, and got back a populated byte[], without any
> exceptions. What would it use to determine that one of the side affects of
> GSSContextImpl#acceptSecContext hasn't succeeded?
>
> Does the above make sense? Please do get in touch if I an provide any
> other assistance in helping with the issue, and thanks again to everyone
> looking into it.
>
>
>
> On Thu, Apr 23, 2015 at 1:58 AM, Weijun Wang <weijun.wang at oracle.com>
> wrote:
>
>> 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?
>>>>>
>>>>>
>>>>>
>>>>
>
>
> --
> Regards,
>
> Daniel Jones
> EngineerBetter.com
>

-- 
Regards,

Daniel Jones
EngineerBetter.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20150423/9aca70df/attachment.htm>