Bug in SunNativeProvider

[Jan Kalina]

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> 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>
> 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/20180104/41355baa/attachment.htm>