[JBoss JIRA] (JBEE-162) JAXWS SPI Provider should call ServiceLoader's load method within a privileged block
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/JBEE-162?page=com.atlassian.jira.plugin.s... ]
Ivo Studensky resolved JBEE-162.
--------------------------------
Resolution: Done
Fixed in jboss-jaxws-api_2.2_spec-2.0.3.Final.
> JAXWS SPI Provider should call ServiceLoader's load method within a privileged block
> ------------------------------------------------------------------------------------
>
> Key: JBEE-162
> URL: https://issues.jboss.org/browse/JBEE-162
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-jaxws-api
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> The JAXWS SPI {{Provider}} uses {{ServiceLoader}} to look for user specified provider implementations. When invoking {{load}} method on the {{ServiceLoader}}, read permission on the relevant jar is required.
> stacktrace:
> {noformat}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/studensky/work/git/jboss-eap-myfork5/dist/target/wildfly-10.0.0.Final-SNAPSHOT/modules/system/layers/base/org/jboss/ws/cxf/jbossws-cxf-factories/main/jbossws-cxf-factories-5.1.2.Final.jar" "read")" in code source "(vfs:/content/ws-serviceref-example.jar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377)
> at java.util.zip.ZipFile.<init>(ZipFile.java:210)
> at java.util.zip.ZipFile.<init>(ZipFile.java:149)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:99)
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1045)
> at java.util.ServiceLoader.parse(ServiceLoader.java:304)
> at java.util.ServiceLoader.access$200(ServiceLoader.java:185)
> at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357)
> at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)
> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> at javax.xml.ws.spi.Provider$1.run(Provider.java:154)
> at javax.xml.ws.spi.Provider$1.run(Provider.java:152)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.xml.ws.spi.Provider.getProviderUsingServiceLoader(Provider.java:152)
> at javax.xml.ws.spi.Provider.provider(Provider.java:108)
> ... 102 more
> {noformat}
> Note: {{java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)}} calls {{doPrivileged}} block with an {{AccessControlContext}} cached from the {{load}} method invocation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ELY-428) HTTP Mechanism configuration during deployment
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-428?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-428:
---------------------------------
Fix Version/s: 1.1.0.Beta5
> HTTP Mechanism configuration during deployment
> ----------------------------------------------
>
> Key: ELY-428
> URL: https://issues.jboss.org/browse/ELY-428
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Affects Versions: 1.0.2.Final
> Reporter: Pedro Igor
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta5
>
>
> It should be possible to configure a HTTP mechanism during deployment in order to parse/load configuration and reuse it in subsequent requests to an application.
> The most common use case for that is around mechanisms that need to read some configuration from inside a deployment (or provided by the mech config) when it is being deployed to the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ELY-428) HTTP Mechanism configuration during deployment
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-428?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-428:
---------------------------------
Priority: Critical (was: Major)
> HTTP Mechanism configuration during deployment
> ----------------------------------------------
>
> Key: ELY-428
> URL: https://issues.jboss.org/browse/ELY-428
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Affects Versions: 1.0.2.Final
> Reporter: Pedro Igor
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta5
>
>
> It should be possible to configure a HTTP mechanism during deployment in order to parse/load configuration and reuse it in subsequent requests to an application.
> The most common use case for that is around mechanisms that need to read some configuration from inside a deployment (or provided by the mech config) when it is being deployed to the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ELY-428) HTTP Mechanism configuration during deployment
by Pedro Igor (JIRA)
Pedro Igor created ELY-428:
------------------------------
Summary: HTTP Mechanism configuration during deployment
Key: ELY-428
URL: https://issues.jboss.org/browse/ELY-428
Project: WildFly Elytron
Issue Type: Enhancement
Components: HTTP
Affects Versions: 1.0.2.Final
Reporter: Pedro Igor
Assignee: Darran Lofthouse
It should be possible to configure a HTTP mechanism during deployment in order to parse/load configuration and reuse it in subsequent requests to an application.
The most common use case for that is around mechanisms that need to read some configuration from inside a deployment (or provided by the mech config) when it is being deployed to the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2021?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2021:
---------------------------
Description:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios to test
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* R sends a new view consisting of the existing view plus R
* If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
h5. The rogue node installing a new secret key in all members (ENCRYPT)
* R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
* Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
was:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios to test
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* TBD
h5. The rogue node installing a new secret key in all members (ENCRYPT)
> Prevent messages from non-members
> ---------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
> For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
> * Send messages to the cluster
> * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
> * Install a new view including itself
> * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
> h3. Goals
> 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
> 2. Prevent a non-member from receiving any cluster messages
> The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
> h3. Proposed solution
> * Use ENCRYPT for encryption of the payload *and the headers*
> * Now _every message_ carries an encrypt header
> * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
> * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
> ** If the message doesn't have an encrypt header, it will be dropped
> * For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
> ** Views and MergeViews: they are stored in the payload ({{GMS}})
> ** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
> h3. Scenarios to test
> h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
> * A rogue member R could catch a message from P by simply joining the same multicast group and port
> * R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
> * However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
> *R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
> h5. Installing a rogue view
> * This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
> * R sends a new view consisting of the existing view plus R
> * If ENCRYPT passes the message up because it doesn't discard message without encrypt header, GMS will install the new view!
> h5. The rogue node installing a new secret key in all members (ENCRYPT)
> * R sends a {{SECRETKEY}} msg with a new shared key, encrypted with its public key
> * Everyone install the new shared secret and R can now receive encrypted messages from cluster members!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2021?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2021:
---------------------------
Description:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios to test
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* TBD
h5. The rogue node installing a new secret key in all members (ENCRYPT)
was:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* TBD
h5. The rogue node installing a new secret key in all members (ENCRYPT)
> Prevent messages from non-members
> ---------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
> For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
> * Send messages to the cluster
> * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
> * Install a new view including itself
> * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
> h3. Goals
> 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
> 2. Prevent a non-member from receiving any cluster messages
> The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
> h3. Proposed solution
> * Use ENCRYPT for encryption of the payload *and the headers*
> * Now _every message_ carries an encrypt header
> * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
> * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
> ** If the message doesn't have an encrypt header, it will be dropped
> * For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
> ** Views and MergeViews: they are stored in the payload ({{GMS}})
> ** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
> h3. Scenarios to test
> h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
> * A rogue member R could catch a message from P by simply joining the same multicast group and port
> * R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
> * However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
> *R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
> h5. Installing a rogue view
> * This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
> * TBD
> h5. The rogue node installing a new secret key in all members (ENCRYPT)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2021?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2021:
---------------------------
Description:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
* This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
* TBD
h5. The rogue node installing a new secret key in all members (ENCRYPT)
was:
Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
* Send messages to the cluster
* Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
* Install a new view including itself
* Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
h3. Goals
1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
2. Prevent a non-member from receiving any cluster messages
The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
h3. Proposed solution
* Use ENCRYPT for encryption of the payload *and the headers*
* Now _every message_ carries an encrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
** If the message doesn't have an encrypt header, it will be dropped
* For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
** Views and MergeViews: they are stored in the payload ({{GMS}})
** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
h3. Scenarios
h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
* A rogue member R could catch a message from P by simply joining the same multicast group and port
* R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
* However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
*R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
h5. Installing a rogue view
> Prevent messages from non-members
> ---------------------------------
>
> Key: JGRP-2021
> URL: https://issues.jboss.org/browse/JGRP-2021
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Although JGroups provides message encryption ({{ENCRYPT}}) and cluster admission control ({{AUTH}}), it _does not_ prevent malicious attacks.
> For example, if a rogue node creates a minimal stack without encryption or authentication, then it is possible for that member to
> * Send messages to the cluster
> * Capture an existing message from a cluster member P, change it (e.g. the seqno) and resend it spooking P's address
> * Install a new view including itself
> * Possibly install a new shared key in {{ENCRYPT}}, thereby being able to _receive_ cluster messages
> h3. Goals
> 1. Prevent cluster members from delivering messages from a non-member (exceptions are join requests from new members and merge requests)
> 2. Prevent a non-member from receiving any cluster messages
> The first goal also prevents rogue views from getting installed, or new shared secrets from being installed into {{ENCRYPT}}.
> h3. Proposed solution
> * Use ENCRYPT for encryption of the payload *and the headers*
> * Now _every message_ carries an encrypt header
> * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
> * When a message is received, it is decrypted using the shared key (this can only be done by members having the shared key)
> ** If the message doesn't have an encrypt header, it will be dropped
> * For some messages that carry their information in the payload rather than the headers, we don't even need to encrypt the entire message (which is faster), e.g.
> ** Views and MergeViews: they are stored in the payload ({{GMS}})
> ** A new secret key sent by the key server is also stored in the payload ({{ENCRYPT}})
> h3. Scenarios
> h5. Catching a message from some member P, modifying it and re-sending it on behalf of P
> * A rogue member R could catch a message from P by simply joining the same multicast group and port
> * R could then increment the last seqno seen, e.g. 23, to 24 and send the message on behalf of P
> * However, the decryption won't work because R doesn't have the shared key. Also, modifying the headers and resending the message won't work as R cannot get at the headers because they're encrypted, too
> *R could still resend the _captures message_ but that's useless as (a) one of the retransmission protocols (UNICAST3 or NAKACK2) will drop the duplicate message
> h5. Installing a rogue view
> * This requires {{ENCRYPT}} to sit somewhere below {{GMS}}
> * TBD
> h5. The rogue node installing a new secret key in all members (ENCRYPT)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6214) Change CMTTxInterceptor.endTransaction() handling of status'
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6214?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-6214:
-------------------------------------
I have made it a blocker as during the work for this I noticed that the status_rolling_back was not resulting in a rollback. Although parallel commit should not be possible in CMT (I still protected for it) parallel rollback is possible due to the reaper.
> Change CMTTxInterceptor.endTransaction() handling of status'
> ------------------------------------------------------------
>
> Key: WFLY-6214
> URL: https://issues.jboss.org/browse/WFLY-6214
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Reporter: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.Final
>
>
> See recent comment [https://developer.jboss.org/message/950898#950898]
> {quote}
> Status.STATUS_COMMITTING:
> Status.STATUS_COMMITTED:
> Status.STATUS_PREPARED:
> Status.STATUS_PREPARING:
> * Someone has called commit in parallel and the transaction is trying to commit so try to commit too: call tm.commit
> {quote}
> I think that TimerCMTTxInterceptor/LifecycleCMTTxInterceptor are using CMTTxInterceptor.endTransaction(), so they shouldn't need changes.
> Status.STATUS_ROLLING_BACK can happen if the reaper has started to rollback the transaction
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6214) Change CMTTxInterceptor.endTransaction() handling of various status'
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6214?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-6214:
--------------------------------
Summary: Change CMTTxInterceptor.endTransaction() handling of various status' (was: Change CMTTxInterceptor.endTransaction() handling of status')
> Change CMTTxInterceptor.endTransaction() handling of various status'
> --------------------------------------------------------------------
>
> Key: WFLY-6214
> URL: https://issues.jboss.org/browse/WFLY-6214
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Reporter: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.Final
>
>
> See recent comment [https://developer.jboss.org/message/950898#950898]
> {quote}
> Status.STATUS_COMMITTING:
> Status.STATUS_COMMITTED:
> Status.STATUS_PREPARED:
> Status.STATUS_PREPARING:
> * Someone has called commit in parallel and the transaction is trying to commit so try to commit too: call tm.commit
> {quote}
> I think that TimerCMTTxInterceptor/LifecycleCMTTxInterceptor are using CMTTxInterceptor.endTransaction(), so they shouldn't need changes.
> Status.STATUS_ROLLING_BACK can happen if the reaper has started to rollback the transaction
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months