October 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4956) EMBARGOED CVE-2020-10718 wildfly: exposed setting of TCCL via the EmbeddedManagedProcess API [eap-7.3.z]

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4956?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4956: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > EMBARGOED CVE-2020-10718 wildfly: exposed setting of TCCL via the EmbeddedManagedProcess API [eap-7.3.z] > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4956 > URL: https://issues.redhat.com/browse/WFCORE-4956 > Project: WildFly Core > Issue Type: Bug > Components: Embedded > Reporter: Kunjan Rathod > Assignee: James Perkins > Priority: Minor > Labels: CVE-2020-10718, Security, SecurityTracking, downstream_dependency, pscomponent:wildfly > Fix For: 13.0.0.Beta5 > > > Security Tracking Issue > Do not make this issue public. > Impact: Low > Public Date: not set > Resolve Bug By: 545 calendar days from the public date > In case the dates above are already past, please evaluate this bug in your next prioritization review and make a decision then. Remember to explicitly set CLOSED:WONTFIX if you decide not to fix this bug. > Please see the Security Errata Policy for further details: https://docs.engineering.redhat.com/x/9RBqB > NOTE THIS ISSUE IS CURRENTLY EMBARGOED, DO NOT MAKE PUBLIC COMMITS OR COMMENTS ABOUT THIS ISSUE. > Flaw: > ----- > EMBARGOED CVE-2020-10718 wildfly: exposed setting of TCCL via the EmbeddedManagedProcess API > https://bugzilla.redhat.com/show_bug.cgi?id=1828476 > The embedded managed process API has two methods exposed as public methods which can bypass the security manager. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5069) libwfssl is not detected by EAP automatically -> cannot use OpenSSL security provider

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5069?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5069: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > libwfssl is not detected by EAP automatically -> cannot use OpenSSL security provider > ------------------------------------------------------------------------------------- > > Key: WFCORE-5069 > URL: https://issues.redhat.com/browse/WFCORE-5069 > Project: WildFly Core > Issue Type: Bug > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Blocker > Fix For: 13.0.0.Beta5 > > > Looks like detection of `libwfssl` is broken in current build. When I try to configure OpenSSL security provider in legacy security, I can see following errors in standalone.log: > {code:java} > 15:39:44,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service15:39:44,704 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739) at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.lang.Thread.run(Thread.java:748)Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLSv1.2, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi) at java.security.Provider$Service.newInstance(Provider.java:1617) at sun.security.jca.GetInstance.getInstance(GetInstance.java:236) at sun.security.jca.GetInstance.getInstance(GetInstance.java:164) at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156) at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105) ... 8 moreCaused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at org.wildfly.openssl.SSL.init(SSL.java:87) at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129) at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi.<init>(OpenSSLContextSPI.java:484) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.security.Provider$Service.newInstance(Provider.java:1595) ... 12 moreCaused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.wildfly.openssl.SSL.init(SSL.java:82) ... 19 moreCaused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1124) at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288) ... 24 more > 15:39:44,818 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("core-service" => "management"), ("security-realm" => "ApplicationRealm")]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context" => "WFLYDM0018: Unable to start service Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLSv1.2, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_2_ContextSpi) Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException Caused by: java.lang.reflect.InvocationTargetException Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path"}} {code} > > This is a regression against previous release - {{EAP7.3.1}}. Expected behaviour is no error in the log, libwfssl is loaded successfully and OpenSSL is correctly used for TLS connections. > Note - there has been a change in the location of the particular libwfssl native binaries in the distribution, see https://github.com/wildfly-security/wildfly-openssl/commit/c5c07d3dc0d637... > {code:title=7.3.1} > $ find . -name *wfssl* > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-sparcv9/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-x86_64/wfssl.dll > ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-i386/wfssl.dll > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-i386/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-x86_64/libwfssl.so > {code} > and > {code:title=7.4.0.CD20-CR1} > $ find . -name *ssl* > ./modules/system/layers/base/org/wildfly/openssl > ./modules/system/layers/base/org/wildfly/openssl/main/wildfly-openssl-java-1.1.0.Final-redhat-00001.jar > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-sparcv9/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-x86_64/wfssl.dll > ./modules/system/layers/base/org/wildfly/openssl/main/lib/win-i386/wfssl.dll > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-s390x/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/el8-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/el7-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/el6-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/el6-i386/libwfssl.so > ./modules/system/layers/base/org/wildfly/security/elytron-private/main/wildfly-elytron-ssl-1.12.1.Final-redhat-00001.jar > {code} > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5084) Why does the elytron layer bring in access control?

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5084?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5084: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > Why does the elytron layer bring in access control? > --------------------------------------------------- > > Key: WFCORE-5084 > URL: https://issues.redhat.com/browse/WFCORE-5084 > Project: WildFly Core > Issue Type: Task > Components: Build System, Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > The following shows the set of changes created by adding the elytron layer to a provisioned server: > https://gist.github.com/darranl/68f4a3d60560dae9a9225ec1a0e35a9f/revisions > This includes the following: > {code:xml} > <management> > <access-control provider="simple"> > <role-mapping> > <role name="SuperUser"> > <include> > <user name="$local"/> > </include> > </role> > </role-mapping> > </access-control> > </management> > {code} > Shouldn't this section be added if any form of authenticated management is added instead? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5079) Adjust management layers to be secured by Elytron or legacy security only

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5079?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5079: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > Adjust management layers to be secured by Elytron or legacy security only > ------------------------------------------------------------------------- > > Key: WFCORE-5079 > URL: https://issues.redhat.com/browse/WFCORE-5079 > Project: WildFly Core > Issue Type: Task > Components: Build System, Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > At the moment it is only in the documentation that it is unsecured, a list of layers could be created similar to: > {code:xml} > <configs> > <config> > <name>standalone.xml</name> > <model>standalone</model> > <layers> > <layer>management</layer> > <layer>remoting</layer> > <layer>elytron</layer> > <layer>web-server</layer> > </layers> > </config> > {code} > From a code review of a snippet like this unless the documentation is cross referenced nothing looks out of place, if instead management was renamed unsecured-management it would be obvious in a review. > The following gist diff show the effect each of the three management layers presently has on the configuration. > * management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * secure-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... > * legacy-management - https://gist.github.com/darranl/e9f1c5a943684ce124c35638e376644f/revision... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5075) Upgrade WildFly OpenSSL to 1.1.2.Final

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5075?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5075: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > Upgrade WildFly OpenSSL to 1.1.2.Final > -------------------------------------- > > Key: WFCORE-5075 > URL: https://issues.redhat.com/browse/WFCORE-5075 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 13.0.0.Beta5 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5076) remoting http-connector silently accepts invalid security-realm

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5076?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5076: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > remoting http-connector silently accepts invalid security-realm > --------------------------------------------------------------- > > Key: WFCORE-5076 > URL: https://issues.redhat.com/browse/WFCORE-5076 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > If the remoting subsystem is changed to the following: > {code:xml} > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="OtherRealm"/> > </subsystem> > {code} > The server starts without error, however attempting to establish a connection fails. > {code} > ./jboss-cli.sh -c --controller=remote+http://localhost:8080 > Failed to connect to the controller: The controller is not available at localhost:8080: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: Invalid response code 200 > {code} > Although the CLI can not do anything over port 8080 it should be able to initiate a remoting connection i.e. > {code} > ./jboss-cli.sh -c --controller=remote+http://localhost:8080 > Failed to connect to the controller: The controller is not available at localhost:8080: org.jboss.remoting3.ServiceOpenException: Unknown service name management: Unknown service name management > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5087) Add support for the -secmgr argument for bootable jar

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5087?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5087: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > Add support for the -secmgr argument for bootable jar > ----------------------------------------------------- > > Key: WFCORE-5087 > URL: https://issues.redhat.com/browse/WFCORE-5087 > Project: WildFly Core > Issue Type: Task > Components: Bootable JAR > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta5 > > > If a SecurityManager is to be installed it should be the WildFlySecurityManager -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5086) Embedded mode sets jboss.server.content.dir incorrectly

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5086?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5086: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > Embedded mode sets jboss.server.content.dir incorrectly > ------------------------------------------------------- > > Key: WFCORE-5086 > URL: https://issues.redhat.com/browse/WFCORE-5086 > Project: WildFly Core > Issue Type: Bug > Components: Embedded > Reporter: Bartosz Spyrko-Smietanko > Assignee: Bartosz Spyrko-Smietanko > Priority: Major > Fix For: 13.0.0.Beta5 > > > During embedded server startup some properties are set if they're not yet present, however the logic for establishing some of them is different from normal mode. > On normal startup if the jboss.server.data.dir is present 'jboss.server.content.dir' property would be set to ${jboss.server.data.dir}/content [1]. In embedded scenario it is instead set to ${jboss.server.base.dir}/standalone/data/content [2]. > [1] https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... > [2] https://github.com/wildfly/wildfly-core/blob/master/embedded/src/main/jav... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5091) Upgrade WildFly Elytron to 1.13.0.Final

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5091?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5091: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > Upgrade WildFly Elytron to 1.13.0.Final > --------------------------------------- > > Key: WFCORE-5091 > URL: https://issues.redhat.com/browse/WFCORE-5091 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Bartosz Spyrko-Smietanko > Assignee: Farah Juma > Priority: Major > Labels: downstream_dependency > Fix For: 13.0.0.Beta6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5089) FailedOperationTransformationConfig corrects only one attribute

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-5089?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-5089: -------------------------------- Fix Version/s: (was: 13.0.0.Final) > FailedOperationTransformationConfig corrects only one attribute > --------------------------------------------------------------- > > Key: WFCORE-5089 > URL: https://issues.redhat.com/browse/WFCORE-5089 > Project: WildFly Core > Issue Type: Bug > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Priority: Major > Fix For: 13.0.0.Beta5 > > > FailedOperationTransformationConfig can be initialized with many attributes but during correct attempt it breaks the loop after the first attribute. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2020