February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9620) ServletContext.getResourceAsStream, for deployments which have (Java EE) servlet overlays, serves files which are outside of the deployment

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-9620?page=com.atlassian.jira.plugin.... ] Yeray Borges updated WFLY-9620: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/10748, https://github.com/wildfly/wildfly/pull/10784, https://github.com/wildfly/wildfly/pull/10815, https://github.com/wildfly/wildfly/pull/10898 (was: https://github.com/wildfly/wildfly/pull/10748, https://github.com/wildfly/wildfly/pull/10784, https://github.com/wildfly/wildfly/pull/10815, https://issues.jboss.org/browse/WFLY-9620) > ServletContext.getResourceAsStream, for deployments which have (Java EE) servlet overlays, serves files which are outside of the deployment > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9620 > URL: https://issues.jboss.org/browse/WFLY-9620 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.2.Final, 10.1.0.Final, 11.0.0.Final > Reporter: Laurent ROUSSEL > Assignee: Yeray Borges > Priority: Critical > Fix For: 12.0.0.Beta1 > > > A user has reported in the forums that there appears to be an issue (since 9.0.x till present 11.0.0 WildFly releases) where files like `/etc/passwd` are served by the web container to the clients, when the client requests a crafted URL against a Java EE deployment which has (Java EE) servlet overlays. Please see the referenced forum thread[1] for more details. > Although, the steps noted in that thread involves Spring framework and gets triggered in a very specific way, the root cause appears to be the call to `ServletContext.getResourceAsInputStream` (which is what the spring framework ends up calling with a path like "/../../../../../../../..//etc/passwd", ends up actually serving the resource even if the path is outside the scope of the deployment to which the servlet context belongs. > I could reproduce this against the latest WildFly in a simple test case that's here [2] > [1] https://developer.jboss.org/thread/276826 > [2] https://github.com/jaikiran/wildfly/commit/ed05258aa824ab91a52ef6554e9707... > P.S: The credit for reporting this issue should go to Laurent Roussel who reported this in the forum thread, but I don't have access to change the "Reporter" field of the JIRA -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9620) ServletContext.getResourceAsStream, for deployments which have (Java EE) servlet overlays, serves files which are outside of the deployment

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-9620?page=com.atlassian.jira.plugin.... ] Yeray Borges reopened WFLY-9620: -------------------------------- Reopen a new PR was sent adding some changes in the test case to make it possible execute it in previous versions of Undertow. > ServletContext.getResourceAsStream, for deployments which have (Java EE) servlet overlays, serves files which are outside of the deployment > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9620 > URL: https://issues.jboss.org/browse/WFLY-9620 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.2.Final, 10.1.0.Final, 11.0.0.Final > Reporter: Laurent ROUSSEL > Assignee: Yeray Borges > Priority: Critical > Fix For: 12.0.0.Beta1 > > > A user has reported in the forums that there appears to be an issue (since 9.0.x till present 11.0.0 WildFly releases) where files like `/etc/passwd` are served by the web container to the clients, when the client requests a crafted URL against a Java EE deployment which has (Java EE) servlet overlays. Please see the referenced forum thread[1] for more details. > Although, the steps noted in that thread involves Spring framework and gets triggered in a very specific way, the root cause appears to be the call to `ServletContext.getResourceAsInputStream` (which is what the spring framework ends up calling with a path like "/../../../../../../../..//etc/passwd", ends up actually serving the resource even if the path is outside the scope of the deployment to which the servlet context belongs. > I could reproduce this against the latest WildFly in a simple test case that's here [2] > [1] https://developer.jboss.org/thread/276826 > [2] https://github.com/jaikiran/wildfly/commit/ed05258aa824ab91a52ef6554e9707... > P.S: The credit for reporting this issue should go to Laurent Roussel who reported this in the forum thread, but I don't have access to change the "Reporter" field of the JIRA -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9620) ServletContext.getResourceAsStream, for deployments which have (Java EE) servlet overlays, serves files which are outside of the deployment

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-9620?page=com.atlassian.jira.plugin.... ] Yeray Borges updated WFLY-9620: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/10748, https://github.com/wildfly/wildfly/pull/10784, https://github.com/wildfly/wildfly/pull/10815, https://issues.jboss.org/browse/WFLY-9620 (was: https://github.com/wildfly/wildfly/pull/10748, https://github.com/wildfly/wildfly/pull/10784, https://github.com/wildfly/wildfly/pull/10815) > ServletContext.getResourceAsStream, for deployments which have (Java EE) servlet overlays, serves files which are outside of the deployment > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9620 > URL: https://issues.jboss.org/browse/WFLY-9620 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.2.Final, 10.1.0.Final, 11.0.0.Final > Reporter: Laurent ROUSSEL > Assignee: Yeray Borges > Priority: Critical > Fix For: 12.0.0.Beta1 > > > A user has reported in the forums that there appears to be an issue (since 9.0.x till present 11.0.0 WildFly releases) where files like `/etc/passwd` are served by the web container to the clients, when the client requests a crafted URL against a Java EE deployment which has (Java EE) servlet overlays. Please see the referenced forum thread[1] for more details. > Although, the steps noted in that thread involves Spring framework and gets triggered in a very specific way, the root cause appears to be the call to `ServletContext.getResourceAsInputStream` (which is what the spring framework ends up calling with a path like "/../../../../../../../..//etc/passwd", ends up actually serving the resource even if the path is outside the scope of the deployment to which the servlet context belongs. > I could reproduce this against the latest WildFly in a simple test case that's here [2] > [1] https://developer.jboss.org/thread/276826 > [2] https://github.com/jaikiran/wildfly/commit/ed05258aa824ab91a52ef6554e9707... > P.S: The credit for reporting this issue should go to Laurent Roussel who reported this in the forum thread, but I don't have access to change the "Reporter" field of the JIRA -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4576) JCE jar file inside a deployment fails the signature check

by Eric Hodges (JIRA)

[ https://issues.jboss.org/browse/WFLY-4576?page=com.atlassian.jira.plugin.... ] Eric Hodges commented on WFLY-4576: ----------------------------------- I've opened a bug with Oracle about the underlying issue. [JDK-8198247|https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8198274] > JCE jar file inside a deployment fails the signature check > ------------------------------------------------------------ > > Key: WFLY-4576 > URL: https://issues.jboss.org/browse/WFLY-4576 > Project: WildFly > Issue Type: Bug > Components: VFS > Affects Versions: 9.0.0.Beta2 > Environment: Wildfly build from master on April 22, 2015 > Reporter: Tom Fonteyne > Attachments: bouncycastle.zip > > > deploy a war file which contains the bouncycastle (or any other JCE) signed jar file. Initialise and try to use a cipher results in a failure due to VFS not being able to read and verify the file -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9845) @Singleton @Startup classes inheriting from a class containing a @PostConstruct method will not create a transaction

by Christopher Czyba (JIRA)

Christopher Czyba created WFLY-9845: --------------------------------------- Summary: @Singleton @Startup classes inheriting from a class containing a @PostConstruct method will not create a transaction Key: WFLY-9845 URL: https://issues.jboss.org/browse/WFLY-9845 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.Final, 9.0.0.Final Reporter: Christopher Czyba Attachments: singleton-postconstruct-transaction.zip, standalone.log During an update from wildfly 8.2.0.Final to 11.0.0.Final I have noticed the following issue: Given an abstract base class B with an @PostConstruct annotated method and a derived class D with the annotations @Singleton and @Startup. When the @PostConstruct method is called, no transaction is started. According to the [EJB 3.2 Specification|http://download.oracle.com/otn-pub/jcp/ejb-3_2-fr-eval-spec...] section 4.8.3, I would expect the container to start a new transaction, as the default transaction attribute is REQUIRED. I have attached source for a war showcasing this issue. On deploying the resulting war on a new wildfly instance, the log should contain the following two lines: {{14:13:06,410 INFO [stdout] (ServerService Thread Pool -- 20) Singleton Hierarchy: transaction status: 6 14:13:06,410 INFO [stdout] (ServerService Thread Pool -- 58) Singleton2 Standalone: transaction status: 0}} A transaction status of 6 says that no transaction exists, while a transaction status of 0 implies that a transaction is ongoing. The war shows that this issue occurs only when using a class hierarchy. I expect the status 0 for both cases. Through testing I noticed that this issue exists since wildfly 9.0.0.Final. I could not find a reason for this behavior from the list of issues for the 9-series release, however. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8494) Sharply increased memory consumption (+ ~50 MB) in full profile

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-8494?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-8494: ----------------------------------- Please direct your question to the user forums. > Sharply increased memory consumption (+ ~50 MB) in full profile > --------------------------------------------------------------- > > Key: WFLY-8494 > URL: https://issues.jboss.org/browse/WFLY-8494 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 11.0.0.Beta1 > > > Memory footprint of full profile after server start jumped 50 megabytes compared to EAP 7.1.0.DR11. Heap dump shows a few huge byte[] arrays referenced by {{io.netty.buffer.PoolChunk}} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1366) Need handle failover for end of DB in HA-Datasource Failover

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1366?page=com.atlassian.jira.plugin... ] Bartosz Spyrko-Śmietanko updated JBJCA-1366: -------------------------------------------- Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/648 > Need handle failover for end of DB in HA-Datasource Failover > ------------------------------------------------------------ > > Key: JBJCA-1366 > URL: https://issues.jboss.org/browse/JBJCA-1366 > Project: IronJacamar > Issue Type: Enhancement > Components: JDBC > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > > If configure below, DB3 does not work failover to DB1. > {noformat} > <connection-url>DB1|DB2|DB3</connection-url> > <url-delimiter>|</url-delimiter> > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2297) Context editor

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2297?page=com.atlassian.jira.plugi... ] Michael Anstis reopened DROOLS-2297: ------------------------------------ > Context editor > -------------- > > Key: DROOLS-2297 > URL: https://issues.jboss.org/browse/DROOLS-2297 > Project: Drools > Issue Type: Sub-task > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > > Refactoring for "Context" editor -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9821) SingletonProvider may be incorrectly initialized with RegistrySingletonProvider

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-9821?page=com.atlassian.jira.plugin.... ] Martin Kouba updated WFLY-9821: ------------------------------- Fix Version/s: 12.0.0.CR1 > SingletonProvider may be incorrectly initialized with RegistrySingletonProvider > ------------------------------------------------------------------------------- > > Key: WFLY-9821 > URL: https://issues.jboss.org/browse/WFLY-9821 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 11.0.0.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 12.0.0.CR1 > > > If a non-CDI deployment (contains no beans.xml nor a bean with a bean defining annotation nor a session bean) attempts to access the CDI container using {{CDI.current()}} before {{TCCLSingletonService}} is started (and {{org.jboss.weld.bootstrap.api.SingletonProvider}} initialized with {{ModuleGroupSingletonProvider}}) then {{SingletonProvider}} is incorrectly initialized with the default impl ({{RegistrySingletonProvider}}). As a result, > subsequent CDI deployments fail with {{java.lang.RuntimeException: SingletonProvider is already initialized...}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2328) Removal of public method broked build

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2328?page=com.atlassian.jira.plugi... ] Jozef Marko reassigned DROOLS-2328: ----------------------------------- Assignee: Jozef Marko (was: Mario Fusco) > Removal of public method broked build > ------------------------------------- > > Key: DROOLS-2328 > URL: https://issues.jboss.org/browse/DROOLS-2328 > Project: Drools > Issue Type: Bug > Affects Versions: 7.7.0.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Priority: Blocker > Fix For: 7.7.0.Final > > > In the [commit|https://github.com/kiegroup/drools/commit/36fee47309d04ceca2a6fd62...] there was removed public method {{getkModule()}} from the class {{KieBuilderImpl}}. This change is incompatible with the code in {{[org.kie.workbench.common.services.backend.builder.core.Builder|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-services/kie-wb-common-services-backend/src/main/java/org/kie/workbench/common/services/backend/builder/core/Builder.java#L196]}} class and cause that the {{kie-wb-common}} project can not be built. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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 February 2018