Bug in SunNativeProvider

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in SunNativeProvider

Jan Kalina
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SunNativeProvider

Jan Kalina
Attaching patch, which fixes described issue for me.

On Thu, Dec 14, 2017 at 4:03 PM, Jan Kalina <[hidden email]> 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


jdk-patch-native.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SunNativeProvider

Valerie Peng


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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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




reproducer-gss.zip (2K) Download Attachment
jkalina-openjdk-native-gss.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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