Bug in SunNativeProvider

[Jan Kalina]

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>
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> 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.getMechFac
>> tory(ProviderList.java:253)
>>     at java.security.jgss/sun.security.jgss.ProviderList.getMechFac
>> tory(ProviderList.java:209)
>>     at java.security.jgss/sun.security.jgss.GSSManagerImpl.getMecha
>> nismContext(GSSManagerImpl.java:234)
>>     at java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSe
>> cContext(GSSContextImpl.java:337)
>>     at java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSe
>> cContext(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/20171222/2b92c37b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reproducer-gss.zip
Type: application/zip
Size: 1825 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20171222/2b92c37b/reproducer-gss.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jkalina-openjdk-native-gss.patch
Type: text/x-patch
Size: 1681 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20171222/2b92c37b/jkalina-openjdk-native-gss.patch>