[JBoss JIRA] (JGRP-2448) FD_SOCK IndexOutOfBoundsException
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2448?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2448.
----------------------------
Resolution: Done
Synchronized access to {{pingable_mbrs}}.
Fixed in 4.x and forward-ported to master.
> FD_SOCK IndexOutOfBoundsException
> ---------------------------------
>
> Key: JGRP-2448
> URL: https://issues.redhat.com/browse/JGRP-2448
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0, 4.2.0
>
>
> {{PD_SOCK.pickNext()}} should iterate up to {{size - 1}}:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
> at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.base/java.util.Objects.checkIndex(Objects.java:372)
> at java.base/java.util.ArrayList.get(ArrayList.java:458)
> at java.base/java.util.Collections$SynchronizedList.get(Collections.java:2424)
> at org.jgroups.util.Util.pickNext(Util.java:2686)
> at org.jgroups.protocols.FD_SOCK.determinePingDest(FD_SOCK.java:762)
> at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:408)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13061) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13061?page=com.atlassian.jira.plugi... ]
Ingo Weiss updated WFLY-13061:
------------------------------
Description: (was: Customer application registers Bouncy Castle as a JCE provider with in Picketlink. There is a bug in Bouncy castle when it is used with Java 11.0.5 and later that causes a crash due to a missing null pointer check. The issue is patched upstream, and they would like the patch applied to the version we release with JBoss EAP.
The attached java file is the file from Bouncy castle 1.60 with the upstream patch applied so it can be compared to the originaly version
Their complete report:
{quote}
This results in BC implementations of various crypto algorithms being used, e.g., for TLS connections.
Unfortunately, all currently available releases of the BC crypto provider [1] (also Beta 1.65b02 [2]) contain a bug which breaks TLS handshakes when ECDHE key exchange is used. This key exchange mechanism requires the data transferred between the peers to be signed using RSASSA-PSS -- a signature scheme whose implementation in BC lacks a null check during its initialization phase.
The problem only occurs since OpenJDK 11.0.5 and 13 due to a regression introduced in OpenJDK by [3] which fixed another compatibility issue with BC. Downgrading the installed JDK to 11.0.4 is not an option, as the issue fixed by [1] will arise and we would lose a number of JDK security fixes. I also strongly believe that BC instead of the JDK is the right place to resolve the defect.
An issue has been opened with BC in [4] which has resulted in a merged pull request in [5], but since there is no ETA on a release of BC that will incorporate this fix, we need a viable interim solution to the problem, otherwise TLS connections with JBoss will not work in our environment.
I've merged the fix from [5] locally to version 1.60 of the BC provider and successfully tested it by manually adjusting the Jboss module org.bouncycastle to use my own patched version of bcprov-jdk15on. Since our client insists on an official solution from Red Hat, I'd like to know if you could build a one-off patch for BC provider for us. I will attach the changed class org.bouncycastle.jcajce.provider.asymmetric.rsa.PSSSignatureSpi for BC 1.60 to this ticket.
[1] https://www.bouncycastle.org/java.html
[2] https://downloads.bouncycastle.org/betas/
[3] https://bugs.openjdk.java.net/browse/JDK-8216039
[4] https://github.com/bcgit/bc-java/issues/633
[5] https://github.com/bcgit/bc-java/pull/632
{quote})
> Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
> -----------------------------------------------------------------------------
>
> Key: WFLY-13061
> URL: https://issues.redhat.com/browse/WFLY-13061
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 19.0.0.Beta2
> Reporter: Ingo Weiss
> Assignee: Bartosz Baranowski
> Priority: Major
> Labels: bouncycastle, java11, picketlink
> Attachments: PSSSignatureSpi.java
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13061) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13061?page=com.atlassian.jira.plugi... ]
Ingo Weiss updated WFLY-13061:
------------------------------
Workaround Description: (was: The customer has temporarily worked around it by manually patching their version of bouncy castle, but they have a client that requires the delivery to use all supported JBoss EAP components.)
> Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
> -----------------------------------------------------------------------------
>
> Key: WFLY-13061
> URL: https://issues.redhat.com/browse/WFLY-13061
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 19.0.0.Beta2
> Reporter: Ingo Weiss
> Assignee: Bartosz Baranowski
> Priority: Major
> Labels: bouncycastle, java11, picketlink
> Attachments: PSSSignatureSpi.java
>
>
> Customer application registers Bouncy Castle as a JCE provider with in Picketlink. There is a bug in Bouncy castle when it is used with Java 11.0.5 and later that causes a crash due to a missing null pointer check. The issue is patched upstream, and they would like the patch applied to the version we release with JBoss EAP.
> The attached java file is the file from Bouncy castle 1.60 with the upstream patch applied so it can be compared to the originaly version
> Their complete report:
> {quote}
> This results in BC implementations of various crypto algorithms being used, e.g., for TLS connections.
> Unfortunately, all currently available releases of the BC crypto provider [1] (also Beta 1.65b02 [2]) contain a bug which breaks TLS handshakes when ECDHE key exchange is used. This key exchange mechanism requires the data transferred between the peers to be signed using RSASSA-PSS -- a signature scheme whose implementation in BC lacks a null check during its initialization phase.
> The problem only occurs since OpenJDK 11.0.5 and 13 due to a regression introduced in OpenJDK by [3] which fixed another compatibility issue with BC. Downgrading the installed JDK to 11.0.4 is not an option, as the issue fixed by [1] will arise and we would lose a number of JDK security fixes. I also strongly believe that BC instead of the JDK is the right place to resolve the defect.
> An issue has been opened with BC in [4] which has resulted in a merged pull request in [5], but since there is no ETA on a release of BC that will incorporate this fix, we need a viable interim solution to the problem, otherwise TLS connections with JBoss will not work in our environment.
> I've merged the fix from [5] locally to version 1.60 of the BC provider and successfully tested it by manually adjusting the Jboss module org.bouncycastle to use my own patched version of bcprov-jdk15on. Since our client insists on an official solution from Red Hat, I'd like to know if you could build a one-off patch for BC provider for us. I will attach the changed class org.bouncycastle.jcajce.provider.asymmetric.rsa.PSSSignatureSpi for BC 1.60 to this ticket.
> [1] https://www.bouncycastle.org/java.html
> [2] https://downloads.bouncycastle.org/betas/
> [3] https://bugs.openjdk.java.net/browse/JDK-8216039
> [4] https://github.com/bcgit/bc-java/issues/633
> [5] https://github.com/bcgit/bc-java/pull/632
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13061) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13061?page=com.atlassian.jira.plugi... ]
Ingo Weiss updated WFLY-13061:
------------------------------
Steps to Reproduce: (was: Asked customer for specific configuration information)
> Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
> -----------------------------------------------------------------------------
>
> Key: WFLY-13061
> URL: https://issues.redhat.com/browse/WFLY-13061
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 19.0.0.Beta2
> Reporter: Ingo Weiss
> Assignee: Bartosz Baranowski
> Priority: Major
> Labels: bouncycastle, java11, picketlink
> Attachments: PSSSignatureSpi.java
>
>
> Customer application registers Bouncy Castle as a JCE provider with in Picketlink. There is a bug in Bouncy castle when it is used with Java 11.0.5 and later that causes a crash due to a missing null pointer check. The issue is patched upstream, and they would like the patch applied to the version we release with JBoss EAP.
> The attached java file is the file from Bouncy castle 1.60 with the upstream patch applied so it can be compared to the originaly version
> Their complete report:
> {quote}
> This results in BC implementations of various crypto algorithms being used, e.g., for TLS connections.
> Unfortunately, all currently available releases of the BC crypto provider [1] (also Beta 1.65b02 [2]) contain a bug which breaks TLS handshakes when ECDHE key exchange is used. This key exchange mechanism requires the data transferred between the peers to be signed using RSASSA-PSS -- a signature scheme whose implementation in BC lacks a null check during its initialization phase.
> The problem only occurs since OpenJDK 11.0.5 and 13 due to a regression introduced in OpenJDK by [3] which fixed another compatibility issue with BC. Downgrading the installed JDK to 11.0.4 is not an option, as the issue fixed by [1] will arise and we would lose a number of JDK security fixes. I also strongly believe that BC instead of the JDK is the right place to resolve the defect.
> An issue has been opened with BC in [4] which has resulted in a merged pull request in [5], but since there is no ETA on a release of BC that will incorporate this fix, we need a viable interim solution to the problem, otherwise TLS connections with JBoss will not work in our environment.
> I've merged the fix from [5] locally to version 1.60 of the BC provider and successfully tested it by manually adjusting the Jboss module org.bouncycastle to use my own patched version of bcprov-jdk15on. Since our client insists on an official solution from Red Hat, I'd like to know if you could build a one-off patch for BC provider for us. I will attach the changed class org.bouncycastle.jcajce.provider.asymmetric.rsa.PSSSignatureSpi for BC 1.60 to this ticket.
> [1] https://www.bouncycastle.org/java.html
> [2] https://downloads.bouncycastle.org/betas/
> [3] https://bugs.openjdk.java.net/browse/JDK-8216039
> [4] https://github.com/bcgit/bc-java/issues/633
> [5] https://github.com/bcgit/bc-java/pull/632
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13061) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13061?page=com.atlassian.jira.plugi... ]
Ingo Weiss updated WFLY-13061:
------------------------------
Labels: bouncycastle java11 picketlink (was: bouncycastle java11 picketlink upstream upstream-fixed)
> Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
> -----------------------------------------------------------------------------
>
> Key: WFLY-13061
> URL: https://issues.redhat.com/browse/WFLY-13061
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 19.0.0.Beta2
> Reporter: Ingo Weiss
> Assignee: Bartosz Baranowski
> Priority: Major
> Labels: bouncycastle, java11, picketlink
> Attachments: PSSSignatureSpi.java
>
>
> Customer application registers Bouncy Castle as a JCE provider with in Picketlink. There is a bug in Bouncy castle when it is used with Java 11.0.5 and later that causes a crash due to a missing null pointer check. The issue is patched upstream, and they would like the patch applied to the version we release with JBoss EAP.
> The attached java file is the file from Bouncy castle 1.60 with the upstream patch applied so it can be compared to the originaly version
> Their complete report:
> {quote}
> This results in BC implementations of various crypto algorithms being used, e.g., for TLS connections.
> Unfortunately, all currently available releases of the BC crypto provider [1] (also Beta 1.65b02 [2]) contain a bug which breaks TLS handshakes when ECDHE key exchange is used. This key exchange mechanism requires the data transferred between the peers to be signed using RSASSA-PSS -- a signature scheme whose implementation in BC lacks a null check during its initialization phase.
> The problem only occurs since OpenJDK 11.0.5 and 13 due to a regression introduced in OpenJDK by [3] which fixed another compatibility issue with BC. Downgrading the installed JDK to 11.0.4 is not an option, as the issue fixed by [1] will arise and we would lose a number of JDK security fixes. I also strongly believe that BC instead of the JDK is the right place to resolve the defect.
> An issue has been opened with BC in [4] which has resulted in a merged pull request in [5], but since there is no ETA on a release of BC that will incorporate this fix, we need a viable interim solution to the problem, otherwise TLS connections with JBoss will not work in our environment.
> I've merged the fix from [5] locally to version 1.60 of the BC provider and successfully tested it by manually adjusting the Jboss module org.bouncycastle to use my own patched version of bcprov-jdk15on. Since our client insists on an official solution from Red Hat, I'd like to know if you could build a one-off patch for BC provider for us. I will attach the changed class org.bouncycastle.jcajce.provider.asymmetric.rsa.PSSSignatureSpi for BC 1.60 to this ticket.
> [1] https://www.bouncycastle.org/java.html
> [2] https://downloads.bouncycastle.org/betas/
> [3] https://bugs.openjdk.java.net/browse/JDK-8216039
> [4] https://github.com/bcgit/bc-java/issues/633
> [5] https://github.com/bcgit/bc-java/pull/632
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13061) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13061?page=com.atlassian.jira.plugi... ]
Ingo Weiss updated WFLY-13061:
------------------------------
Summary: Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5 (was: [GSS](7.3.z) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5)
> Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
> -----------------------------------------------------------------------------
>
> Key: WFLY-13061
> URL: https://issues.redhat.com/browse/WFLY-13061
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 19.0.0.Beta2
> Reporter: Ingo Weiss
> Assignee: Bartosz Baranowski
> Priority: Major
> Labels: bouncycastle, java11, picketlink
> Attachments: PSSSignatureSpi.java
>
>
> Customer application registers Bouncy Castle as a JCE provider with in Picketlink. There is a bug in Bouncy castle when it is used with Java 11.0.5 and later that causes a crash due to a missing null pointer check. The issue is patched upstream, and they would like the patch applied to the version we release with JBoss EAP.
> The attached java file is the file from Bouncy castle 1.60 with the upstream patch applied so it can be compared to the originaly version
> Their complete report:
> {quote}
> This results in BC implementations of various crypto algorithms being used, e.g., for TLS connections.
> Unfortunately, all currently available releases of the BC crypto provider [1] (also Beta 1.65b02 [2]) contain a bug which breaks TLS handshakes when ECDHE key exchange is used. This key exchange mechanism requires the data transferred between the peers to be signed using RSASSA-PSS -- a signature scheme whose implementation in BC lacks a null check during its initialization phase.
> The problem only occurs since OpenJDK 11.0.5 and 13 due to a regression introduced in OpenJDK by [3] which fixed another compatibility issue with BC. Downgrading the installed JDK to 11.0.4 is not an option, as the issue fixed by [1] will arise and we would lose a number of JDK security fixes. I also strongly believe that BC instead of the JDK is the right place to resolve the defect.
> An issue has been opened with BC in [4] which has resulted in a merged pull request in [5], but since there is no ETA on a release of BC that will incorporate this fix, we need a viable interim solution to the problem, otherwise TLS connections with JBoss will not work in our environment.
> I've merged the fix from [5] locally to version 1.60 of the BC provider and successfully tested it by manually adjusting the Jboss module org.bouncycastle to use my own patched version of bcprov-jdk15on. Since our client insists on an official solution from Red Hat, I'd like to know if you could build a one-off patch for BC provider for us. I will attach the changed class org.bouncycastle.jcajce.provider.asymmetric.rsa.PSSSignatureSpi for BC 1.60 to this ticket.
> [1] https://www.bouncycastle.org/java.html
> [2] https://downloads.bouncycastle.org/betas/
> [3] https://bugs.openjdk.java.net/browse/JDK-8216039
> [4] https://github.com/bcgit/bc-java/issues/633
> [5] https://github.com/bcgit/bc-java/pull/632
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13061) [GSS](7.3.z) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
by Ingo Weiss (Jira)
[ https://issues.redhat.com/browse/WFLY-13061?page=com.atlassian.jira.plugi... ]
Ingo Weiss moved JBEAP-18638 to WFLY-13061:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13061 (was: JBEAP-18638)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 19.0.0.Beta2
(was: 7.2.5.GA)
Fix Version/s: (was: 7.3.1.GA)
> [GSS](7.3.z) Picketlink: TLS handshakes with ECDHE fail with Bouncy Castle and Java 11.0.5
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13061
> URL: https://issues.redhat.com/browse/WFLY-13061
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 19.0.0.Beta2
> Reporter: Ingo Weiss
> Assignee: Bartosz Baranowski
> Priority: Major
> Labels: bouncycastle, java11, picketlink
> Attachments: PSSSignatureSpi.java
>
>
> Customer application registers Bouncy Castle as a JCE provider with in Picketlink. There is a bug in Bouncy castle when it is used with Java 11.0.5 and later that causes a crash due to a missing null pointer check. The issue is patched upstream, and they would like the patch applied to the version we release with JBoss EAP.
> The attached java file is the file from Bouncy castle 1.60 with the upstream patch applied so it can be compared to the originaly version
> Their complete report:
> {quote}
> This results in BC implementations of various crypto algorithms being used, e.g., for TLS connections.
> Unfortunately, all currently available releases of the BC crypto provider [1] (also Beta 1.65b02 [2]) contain a bug which breaks TLS handshakes when ECDHE key exchange is used. This key exchange mechanism requires the data transferred between the peers to be signed using RSASSA-PSS -- a signature scheme whose implementation in BC lacks a null check during its initialization phase.
> The problem only occurs since OpenJDK 11.0.5 and 13 due to a regression introduced in OpenJDK by [3] which fixed another compatibility issue with BC. Downgrading the installed JDK to 11.0.4 is not an option, as the issue fixed by [1] will arise and we would lose a number of JDK security fixes. I also strongly believe that BC instead of the JDK is the right place to resolve the defect.
> An issue has been opened with BC in [4] which has resulted in a merged pull request in [5], but since there is no ETA on a release of BC that will incorporate this fix, we need a viable interim solution to the problem, otherwise TLS connections with JBoss will not work in our environment.
> I've merged the fix from [5] locally to version 1.60 of the BC provider and successfully tested it by manually adjusting the Jboss module org.bouncycastle to use my own patched version of bcprov-jdk15on. Since our client insists on an official solution from Red Hat, I'd like to know if you could build a one-off patch for BC provider for us. I will attach the changed class org.bouncycastle.jcajce.provider.asymmetric.rsa.PSSSignatureSpi for BC 1.60 to this ticket.
> [1] https://www.bouncycastle.org/java.html
> [2] https://downloads.bouncycastle.org/betas/
> [3] https://bugs.openjdk.java.net/browse/JDK-8216039
> [4] https://github.com/bcgit/bc-java/issues/633
> [5] https://github.com/bcgit/bc-java/pull/632
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (JGRP-2448) FD_SOCK IndexOutOfBoundsException
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2448?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2448:
--------------------------------
If you look at the stack trace, that's not the problem. The issue is that {{pingable_mbrs}} is changed during iteration, as iteration goes from {{[0..size-1]}}.
Hmm, this is terrible code and I've been meaning to change it for a long time... I either need to synchronize access to {{pingable_mbrs}}, or make it concurrent. Downside of the latter solution is that we might end up with an incorrect {{ping_dest}}...
> FD_SOCK IndexOutOfBoundsException
> ---------------------------------
>
> Key: JGRP-2448
> URL: https://issues.redhat.com/browse/JGRP-2448
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 5.0, 4.2.0
>
>
> {{PD_SOCK.pickNext()}} should iterate up to {{size - 1}}:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
> at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.base/java.util.Objects.checkIndex(Objects.java:372)
> at java.base/java.util.ArrayList.get(ArrayList.java:458)
> at java.base/java.util.Collections$SynchronizedList.get(Collections.java:2424)
> at org.jgroups.util.Util.pickNext(Util.java:2686)
> at org.jgroups.protocols.FD_SOCK.determinePingDest(FD_SOCK.java:762)
> at org.jgroups.protocols.FD_SOCK.run(FD_SOCK.java:408)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months