Bug in SunNativeProvider

[Valerie Peng]

Great, thanks!
Valerie

On 1/4/2018 4:51 AM, Jan Kalina wrote:
> Described issues was accepted into Oracle JDK issues:
>
> 1) SunNativeProvider.INSTANCE initialization: 
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194073
> 2) Uninitialized cb->initiator_address: 
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194630
>
> (fixing patches are included in reports too)
>
>
> On Fri, Dec 22, 2017 at 5:44 PM, Jan Kalina <jkalina at redhat.com 
> <mailto:jkalina at redhat.com>> wrote:
>
>     Hi, I was just able to prepare usable reproducer (attaching in ZIP
>     file) and fixing patch of JDK (attaching too).
>     Before I was able to make my usecase working, I has found second
>     issue too - I has included it too.
>
>     Issues and their reproducing:
>
>     1) already described problem of wrong initialized
>     SunNativeProvider.INSTANCE
>
>     This can be reproduced by recreating GSSManager before
>     createGSSContext - ProviderList.factories
>     will be initialized as part of initSecContext/acceptSecContext
>     which will cause using wrong initialized
>     SunNativeProvider.INSTANCE and described exception.
>
>     2) when channel binding is used SIGSEGV occure
>
>     This can be reproduced by setting channel binding without
>     initAddr/acceptAddr.
>     This is caused by sending uninitialized (with random length)
>     cb->initiator_address from JDK to the kerberos.
>     (It is used by krb library for messages checksum calculation even
>     when addrtype is GSS_C_AF_NULLADDR.)
>
>     Attached reproducer-gss.zip reproduces both issues and attached
>     patch fixes both.
>
>     I would welcome merging into OpenJDK. (I am covered by OCA of Red Hat)
>
>     This issue affect both tested JDKs, JKD8u121 and upstream JDK9
>     from mercurial master.
>
>     Thanks,
>     Jan
>
>     On Wed, Dec 20, 2017 at 1:42 AM, Valerie Peng
>     <valerie.peng at oracle.com <mailto:valerie.peng at oracle.com>> wrote:
>
>
>         I will take a look. Do you happen to have a test case that I
>         can reproduce the issue?
>         Thanks,
>         Valerie
>
>
>         On 12/14/2017 9:20 AM, Jan Kalina wrote:
>>         Attaching patch, which fixes described issue for me.
>>
>>         On Thu, Dec 14, 2017 at 4:03 PM, Jan Kalina
>>         <jkalina at redhat.com <mailto:jkalina at redhat.com>> wrote:
>>
>>             I has found bug in SunNativeProvider:
>>
>>             When debug messages are enabled, JDK confirms GSS library
>>             was loaded with mechs:
>>
>>             [GSSLibStub_init] libName=/usr/lib64/libgssapi_krb5.so.2.2
>>             SunNativeGSS: Loaded GSS library:
>>             /usr/lib64/libgssapi_krb5.so.2.2
>>             SunNativeGSS: Native MF for 1.2.840.113554.1.2.2
>>             SunNativeGSS: Native MF for 1.3.6.1.5.2.5
>>             SunNativeGSS: Native MF for 1.3.6.1.5.5.2
>>
>>             But when I try to use it, it claims mechanism with given
>>             OID are not supported:
>>
>>             GSSException: Provider SunNativeGSS does not support
>>             mechanism 1.2.840.113554.1.2.2
>>                 at
>>             java.security.jgss/sun.security.jgss.ProviderList.getMechFactory(ProviderList.java:253)
>>                 at
>>             java.security.jgss/sun.security.jgss.ProviderList.getMechFactory(ProviderList.java:209)
>>                 at
>>             java.security.jgss/sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:234)
>>                 at
>>             java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:337)
>>                 at
>>             java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:302)
>>
>>             *When I has try to debug it, I has found the
>>             SunNativeProvider is created in two instances:*
>>
>>             First instance is created on initialization of
>>             SunNativeProvider.INSTANCE, but it is BEFORE
>>             the mechs are passed into SunNativeProvider.MECH_MAP. The
>>             second instance is created
>>             correctly in ProviderList constructor.
>>
>>             The problem is, in some situations is used the too soon
>>             created SunNativeProvider.INSTANCE,
>>             so the to call throws exception above.
>>
>>             *I think sufficient fix would be to move
>>             SunNativeProvider.INSTANCE declaration after*
>>             *the static constructor (filling the **MECH_MAP) in
>>             SunNativeProvider file.*
>>
>>             Would be possible to fix this?
>>             Should I send a patch?
>>
>>             Thanks
>>             Jan Kalina
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20180104/d9ab32e1/attachment.htm>