<div dir="ltr">Hi all,<div><br></div><div>FYI We just tried switching to Oracle JRE u45, and the same behaviour is exhibited there. </div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 12:25 PM, Daniel Jones <span dir="ltr"><<a href="mailto:daniel.jones@engineerbetter.com" target="_blank">daniel.jones@engineerbetter.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>Thanks to everyone taking the time to look into this.</div><div><br></div><div>Before I get into the detail of the technical issue, can anyone postulate as to <b>how quickly fixes tend to make it into releases of OpenJDK</b>? 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.</div><div><br></div><div>The Spring code in question actually changed this morning to throw a more useful error: <a href="https://github.com/spring-projects/spring-security-kerberos/commit/f046bd7c69d6dad74eb06a7651cd68060b31ff6f" target="_blank">https://github.com/spring-projects/spring-security-kerberos/commit/f046bd7c69d6dad74eb06a7651cd68060b31ff6f</a></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">On the other hand, your program has</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">   context.acceptSecContext(kerb</span><span style="font-size:12.8000001907349px">erosTicket, 0, kerberosTicket.length);<br></span><span style="font-size:12.8000001907349px">   String user = context.getSrcName().toString(</span><span style="font-size:12.8000001907349px">);</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">which is not standard. The acceptSecContext call should be in a loop until a context is established, and then you can call getSrcName().</span></blockquote><div><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">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:</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><ol><li><span style="font-size:12.8000001907349px">Spring's SunJaasKerberosTicketValidator gets a GSSContextImpl, and calls acceptSecContext on it.</span><br></li><li><span style="font-size:12.8000001907349px">The GSSContextImpl calls an overloaded accetSecContext method, which successfully creates a SpNegoContext and assigns it as the mechCtxt member.</span><br></li><li><span style="font-size:12.8000001907349px">GSSContextImpl#acceptSecContext then calls SpNegoContext#acceptSecContext</span><br></li><li><span style="font-size:12.8000001907349px">In SpNegoContext#acceptSecContext we have the new functionality that only looks at the top item of the list of OIDs from the service ticket. </span><br></li><li><span style="font-size:12.8000001907349px">The inner mechContext of the SpNegoContext is not set.</span><br></li><li><span style="font-size:12.8000001907349px">We return back to the Spring code, with a GSSContextImpl wrapping a SpNegoContext</span><br></li><li><span style="font-size:12.8000001907349px">Spring calls GSSContextImpl#getSrcName(), which delegates to SpNegoContext#getSrcName(), which returns null as its mechContext member is null.</span><br></li></ol></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 1:58 AM, Weijun Wang <span dir="ltr"><<a href="mailto:weijun.wang@oracle.com" target="_blank">weijun.wang@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Daniel<br>
<br>
I've read more about your bug report and know what's happening.<br>
<br>
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.<br>
<br>
I believe a lot of people is using the Microsoft OID. I will see if it's possible to recognize both OIDs.<br>
<br>
On the other hand, your program has<br>
<br>
   context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length);<br>
   String user = context.getSrcName().toString();<br>
<br>
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.<br>
<br>
Thanks<br>
Max<div><div><br>
<br>
On 4/23/2015 7:22 AM, Weijun Wang wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Daniel<br>
<br>
Thanks for the report.<br>
<br>
In fact, the bug behind the changeset you mentioned -- 8048194 -- was<br>
just meant to make your case work. Before that, the server blindly<br>
accepts the mechToken and process it no matter if the OID is supported.<br>
Now it first looks at the OID and accept the token if it supports the<br>
OID; otherwise, only the negotiated result (its supported OID) is sent<br>
back, and waits for the client sending the correct mechToken in the next<br>
round.<br>
<br>
It seems the logic above is not implemented correctly, can you show me<br>
the full stack of your NullPointerException? If it includes any<br>
sensitive info you can write me privately.<br>
<br>
Thanks<br>
Max<br>
<br>
On 4/23/2015 12:21 AM, Rob McKenna wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Daniel,<br>
<br>
Thanks for the report, I'm cc'ing the security-dev alias.<br>
<br>
     -Rob<br>
<br>
On 22/04/15 13:10, Daniel Jones wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
Apologies if this is the wrong mailing list - please direct me to the<br>
correct one if so.<br>
<br>
I believe I've found a bug in OpenJDK 1.8.0_40, introduced in commit<br>
d777e2918a77:<br>
<a href="http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java" target="_blank">http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java</a><br>
<br>
<br>
<br>
The change introduced on line 548 means that an authentication<br>
mechanism is<br>
only accepted if the OID of the mechanism desired is the *first* in the<br>
list of mechanisms specified as acceptable in the incoming ticket.<br>
<br>
In the case of my current client their service tickets are specifying 4<br>
acceptable mechanism OIDs, but the only available mechanism's OID<br>
appears<br>
second on that list. So whilst the server *can *satisfy the ticket, the<br>
code change on line 548 prevents this from happening.<br>
<br>
Using the same server code, the same Kerberos KDC, and OpenJDK 1.8.0_31,<br>
everything works. Changing only the JDK results in the mechContext not<br>
being properly populated, which in turn causes a NullPointerException<br>
from<br>
some Spring Security Kerberos code.<br>
<br>
Has anyone else experienced this?<br>
<br>
<br>
</blockquote>
<br>
</blockquote></blockquote>
</div></div></blockquote></div><br></div><br clear="all"><div><br></div></div></div><div class="HOEnZb"><div class="h5">-- <br><div><div dir="ltr">Regards,<div><br></div><div>Daniel Jones</div><div>EngineerBetter.com</div></div></div>
</div></div></blockquote></div><br></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Regards,<div><br></div><div>Daniel Jones</div><div>EngineerBetter.com</div></div></div>