Bug 1236606

Summary: [GSS](6.4.z) Unable to authenticate in SPNEGO Login Module with NullPointerException
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Kunjan Rathod <krathod>
Component: OtherAssignee: Chao Wang <chaowan>
Status: CLOSED CURRENTRELEASE QA Contact: Jiri Truhlar <jtruhlar>
Severity: medium Docs Contact: eap-docs <eap-docs>
Priority: high    
Version: 6.3.2CC: bbaranow, bmaxwell, chaowan, darran.lofthouse, dehort, dpospisi, jason.greene, jboss-set, jtruhlar, rmody, sfolkwil, tfonteyn, vtunka
Target Milestone: CR2   
Target Release: EAP 6.4.7   
Hardware: Unspecified   
OS: Unspecified   
URL: https://github.com/wildfly-security/jboss-negotiation/pull/25
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-17 11:53:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1279552, 1289181    

Description Kunjan Rathod 2015-06-29 14:21:17 UTC
Description of problem:

The configuration with SPNEGO works fine, however from time to time the authentication fails with the following error:


ERROR (HTTP-341)  [org.jboss.security.auth.spi.AbstractServerLoginModule] Unable to authenticate: java.lang.NullPointerException
        at org.jboss.security.negotiation.spnego.SPNEGOLoginModule$AcceptSecContext.run(SPNEGOLoginModule.java:420)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:356)


Version-Release number of selected component (if applicable):

JBoss Security Negotiation 2.3.3.Final

How reproducible:
This happens very rarely (20 times in a day on a system where about 50 users are working) and it is extremely hard to reproduce. 

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

At line 420 in [1], the GSSToken is null
~~~~
           if (respToken != null)
            {
               NegotiationMessage response;
               if (requestMessage instanceof KerberosMessage)
               {
                  response = new KerberosMessage(Constants.KERBEROS_V5, respToken);
               }
               else
               {
                  NegTokenTarg negTokenTarg = new NegTokenTarg();
                  negTokenTarg.setResponseToken(respToken);

                  response = negTokenTarg;
               }
~~~~

It looks like a GSSToken can be or is null, check the line#344 as follows:-
~~~~~~~~~
public Object run()
      {        
         try
         {
            // The message type will have already been checked before this point so we know it is
            // a SPNEGO message.
            NegotiationMessage requestMessage = negotiationContext.getRequestMessage();

            // TODO - Ensure no way to fall through with gssToken still null.
            byte[] gssToken = null;
            if (requestMessage instanceof NegTokenInit)
            {
            ...
~~~~~~~~~

[1] : https://github.com/wildfly-security/jboss-negotiation/blob/2.3.3.Final/jboss-negotiation-spnego/src/main/java/org/jboss/security/negotiation/spnego/SPNEGOLoginModule.java

Comment 9 Darran Lofthouse 2015-10-08 09:57:07 UTC
Overall does sound like someone has demonstrated there is a situation it can fall through and be null, code needs reviewing and modifying to make it null safe.

Comment 11 JBoss JIRA Server 2015-10-26 10:45:21 UTC
Darran Lofthouse <darran.lofthouse> updated the status of jira SECURITY-897 to Resolved

Comment 27 Darran Lofthouse 2016-02-17 16:31:46 UTC
The PR for this BZ has been merged and a subsequent release has been tagged at: -

https://github.com/wildfly-security/jboss-negotiation/tree/2.3.11.Final

Note: This is the only fix in this tag since 2.3.10.Final.

Adding a needinfo as I will leave you to send in the EAP 6 changes to switch to the latest release of JBoss Negotiation.

Comment 31 Petr Penicka 2017-01-17 11:53:39 UTC
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.