November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-868: -------------------------------------------------- Jan Tymel <jtymel(a)redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from ON_QA to VERIFIED > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_0.Final > > Attachments: stacktraces.log > > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-882) Fix for SECURITY-868 breaks flush-cache capability

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-882?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-882: -------------------------------------------------- Jan Tymel <jtymel(a)redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from ON_QA to VERIFIED > Fix for SECURITY-868 breaks flush-cache capability > -------------------------------------------------- > > Key: SECURITY-882 > URL: https://issues.jboss.org/browse/SECURITY-882 > Project: PicketBox > Issue Type: Bug > Components: AS-Integration > Affects Versions: PicketBox_4_0_19.Final > Environment: EAP 6.3.3, JDV 6.1.0 > Reporter: Hisanobu Okuda > Assignee: Stefan Guilhen > > The member field ThreadLocal<CompoundInfo> validatedDomainInfo was introduced for the fix of SECURITY-868. When you are authenticated, a valid security info is stored in the field thread-locally. Then, you flushes the JAAS cache via CLI or API in another thread, org.jboss.security.authentication.JBossCachedAuthenticationManager.flushCache() is invoked, but validatedDomainInfo is not flushed properly, since it is ThreadLocal. As a result, a cached security info is re-used unexpectedly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-888) Revert changes made in SECURITY-868

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-888?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-888: -------------------------------------------------- Jan Tymel <jtymel(a)redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from ON_QA to VERIFIED > Revert changes made in SECURITY-868 > ----------------------------------- > > Key: SECURITY-888 > URL: https://issues.jboss.org/browse/SECURITY-888 > Project: PicketBox > Issue Type: Task > Affects Versions: PicketBox_4_9_1.Final > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_2.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1057) Management console/CLI does not limit the size of uploaded file

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1057?page=com.atlassian.jira.plugi... ] Lin Gao updated WFCORE-1057: ---------------------------- Security: (was: Red Hat Internal) > Management console/CLI does not limit the size of uploaded file > --------------------------------------------------------------- > > Key: WFCORE-1057 > URL: https://issues.jboss.org/browse/WFCORE-1057 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI, Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Lin Gao > Assignee: Lin Gao > Attachments: WFCORE-1057-Management-console-CLI-does-not-limit-th.patch > > > "JBoss management console does not restrict file uploads. A remote attacker could use this flaw to upload a large file through the management console, exhausting all available disk space." > CLI does not limit the size of the uploaded file either, so both 'http' and 'remote' management interface should be fixed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-893) Second security vault warning is displayed even if only one vault definition is present in the server configuration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-893?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-893: -------------------------------------------------- Jan Tymel <jtymel(a)redhat.com> changed the Status of [bug 1181457|https://bugzilla.redhat.com/show_bug.cgi?id=1181457] from ON_QA to VERIFIED > Second security vault warning is displayed even if only one vault definition is present in the server configuration > ------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-893 > URL: https://issues.jboss.org/browse/SECURITY-893 > Project: PicketBox > Issue Type: Bug > Components: JBossSX, Security-SPI > Affects Versions: PicketBox_4_1_0.Beta2 > Reporter: Ivo Studensky > Assignee: Peter Skopek > > The BZ's description: > I have only one vault configured in the standalone.xml but I see following warning message in the server log file after login attempt (bindCredentials login module option uses a vaulted password): > {noformat} > 09:10:58,854 WARN [org.jboss.security] (http-/127.0.0.1:8080-1) PBOX000378: Attempt to create the second Security Vault [org.picketbox.plugins.vault.PicketBoxSecurityVault] is invalid. Only one Security Vault is supported. Change your configuration, please. > {noformat} > This issue is related to the previous fix for bz1055577, \[1\]. The problem needs to be fixed on EAP side in time of Security Subsystem configuration processing. Fix will be provided by bz1181457 \[2\]. > \[1\] https://bugzilla.redhat.com/show_bug.cgi?id=1055577 > \[2\] https://bugzilla.redhat.com/show_bug.cgi?id=1181457 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1091) Kerberos authentication for remoting on hostname which contains uppercase letter

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1091?page=com.atlassian.jira.plugi... ] Lin Gao moved WFLY-5557 to WFCORE-1091: --------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-1091 (was: WFLY-5557) Component/s: Domain Management Remoting Security (was: Domain Management) (was: Remoting) (was: Security) Affects Version/s: 2.0.0.CR9 (was: 10.0.0.CR3) > Kerberos authentication for remoting on hostname which contains uppercase letter > -------------------------------------------------------------------------------- > > Key: WFCORE-1091 > URL: https://issues.jboss.org/browse/WFCORE-1091 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting, Security > Affects Versions: 2.0.0.CR9 > Reporter: Martin Choma > Assignee: Lin Gao > Priority: Critical > > When EAP runs on server, which contains upper case in hostname (e.g. localhost.Localdomain), it is unpossible to make kerberos authentication in remoting to work properly. > JDK constructs TGT-REQ with lower case hostname. But remoting client create connection to EAP with upper case letters, what cause problems. > RFC4120 "The Kerberos Network Authentication Service" [1] in chapter "6.2.1. Name of Server Principals" requires ??Where the name of the host is not case sensitive (for example, with Internet domain names) the name of the host MUST be lowercase.?? > Based on information from RFC, IMHO, EAP should handle such scenario. Either remoting client should send lowercase hostname or security realm should map principal case insensitively and look for lower-case keytab record, e.g. remote/localhost.localdomain. > [1] https://www.ietf.org/rfc/rfc4120.txt -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-670) Node type is not complete at index 0 after tab completion on an empty resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-670?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-670: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1277320 Bugzilla Update: Perform > Node type is not complete at index 0 after tab completion on an empty resource > ------------------------------------------------------------------------------ > > Key: WFCORE-670 > URL: https://issues.jboss.org/browse/WFCORE-670 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: James Perkins > Assignee: Alexey Loubyansky > Priority: Blocker > Fix For: 1.0.0.CR2 > > > Using something like {{/system-property=<TAB>}} with no system properties set results in future commands no longer working. > {code:title=Example Output} > [standalone@localhost:9990 /] /system-property= > The operation name is missing or the format of the operation request is wrong. > [standalone@localhost:9990 /] > [standalone@localhost:9990 /] exit > Node type is not complete at index 0 > [standalone@localhost:9990 /] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/WFLY-5596?page=com.atlassian.jira.plugin.... ] James Livingston commented on WFLY-5596: ---------------------------------------- WFLY-4661 rather. With only 5151 it is still within a management op. > MessageDrivenComponent startDelivery/stopDelivery is not thread safe > -------------------------------------------------------------------- > > Key: WFLY-5596 > URL: https://issues.jboss.org/browse/WFLY-5596 > Project: WildFly > Issue Type: Bug > Components: EJB, JMS > Affects Versions: 10.0.0.CR4 > Reporter: James Livingston > Assignee: Jeff Mesnil > > WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously. > Possible effects include: > * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly > * activate() and deactivate() running in the wrong order if done by separate threads > Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/WFLY-5596?page=com.atlassian.jira.plugin.... ] James Livingston commented on WFLY-5596: ---------------------------------------- That is no longer true in WF 10 (WFLY-5151), MdbDeliveryControllerService.start()/stop() call those methods as well. It can be triggered by clustering events changing HA Singleton status. > MessageDrivenComponent startDelivery/stopDelivery is not thread safe > -------------------------------------------------------------------- > > Key: WFLY-5596 > URL: https://issues.jboss.org/browse/WFLY-5596 > Project: WildFly > Issue Type: Bug > Components: EJB, JMS > Affects Versions: 10.0.0.CR4 > Reporter: James Livingston > Assignee: Jeff Mesnil > > WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously. > Possible effects include: > * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly > * activate() and deactivate() running in the wrong order if done by separate threads > Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-5596?page=com.atlassian.jira.plugin.... ] Jason Greene commented on WFLY-5596: ------------------------------------ I remember glancing at this code and thinking it could be better protected. However, IIRC the only usage point is from management ops, and since these ops are declared as write operations they hold the exclusive management write lock. > MessageDrivenComponent startDelivery/stopDelivery is not thread safe > -------------------------------------------------------------------- > > Key: WFLY-5596 > URL: https://issues.jboss.org/browse/WFLY-5596 > Project: WildFly > Issue Type: Bug > Components: EJB, JMS > Affects Versions: 10.0.0.CR4 > Reporter: James Livingston > Assignee: Jeff Mesnil > > WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously. > Possible effects include: > * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly > * activate() and deactivate() running in the wrong order if done by separate threads > Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 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 November 2015