[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
The goals are therefore:
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 enrypt header
* (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
* Sent messages encrypt not just the payload but also the headers
h3. Scenarios
h4. Installing a rogue view
h4. Catching a message from some member P, modifying it and re-sending it on behalf of P
* thus
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
The goals are therefore:
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 enrypt header
h4.
> 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
> The goals are therefore:
> 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 enrypt header
> * (Let's assume for the moment that {{ENCRYPT}} is configured to use a shared key)
> * Sent messages encrypt not just the payload but also the headers
> h3. Scenarios
> h4. Installing a rogue view
> h4. Catching a message from some member P, modifying it and re-sending it on behalf of P
> * thus
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-3456) Can not call method with generic type parameter with null value
by Trond G. Ziarkowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3456?page=com.atlassian.jira.plugin.... ]
Trond G. Ziarkowski commented on WFLY-3456:
-------------------------------------------
I think that the fix implemented for this issue is wrong.
According to [~dmlloyd]s comment above, the most general method should be chosen and to me that is {{getLastUpdate(Object)}}. Since bridge methods are filtered {{getLastUpdate(Object)}} is not wrapped, and {{getLastUpdate(SimpleOrder)}} is the only candidate available and the changes made in {{resolveAmbiguousWrapper(...)}}, that would have chosen {{getLastUpdate(Object)}}, will never be executed.
The filtering of all bridged methods also has the side effect of filtering "visibility" bridged methods as commented by [~bodist].
Since I am not able to reopen this issue I have created WFLY-6280 to address this.
> Can not call method with generic type parameter with null value
> ---------------------------------------------------------------
>
> Key: WFLY-3456
> URL: https://issues.jboss.org/browse/WFLY-3456
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 8.1.0.Final
> Reporter: Marcel Neuwohner
> Assignee: Farah Juma
> Fix For: 9.0.0.Alpha1
>
>
> If you call a method with a generic type parameter from EL with null as parameter value you get
> {code}
> javax.el.MethodNotFoundException
> Unable to find unambiguous method: SimpleOrderHandler$Proxy$_$$_WeldClientProxy.getLastUpdate(null)
> at
> javax.el.Util.findWrapper(Util.java:322)
> javax.el.Util.findMethod(Util.java:203)
> javax.el.ELUtil.findMethod(ELUtil.java:288)
> javax.el.BeanELResolver.invoke(BeanELResolver.java:527)
> javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
> com.sun.el.parser.AstValue.getValue(AstValue.java:136)
> com.sun.el.parser.AstValue.getValue(AstValue.java:204)
> com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
> org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
> com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6280) Can not call "visibility" bridged methods
by Trond G. Ziarkowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-6280?page=com.atlassian.jira.plugin.... ]
Trond G. Ziarkowski updated WFLY-6280:
--------------------------------------
Steps to Reproduce:
{code:java}
public class VisibilityBridgedMethod {
static class Parent {
public String methodToCall() { return "value"; }
}
public static class Child extends Parent {
// methodToCall() will be bridged by compiler
}
public static void main(String[] args) {
ELProcessor processor = new ELProcessor();
processor.defineBean("child", new Child());
processor.eval("child.methodToCall()");
}
}
{code}
was:
{noformat}
public class VisibilityBridgedMethod {
static class Parent {
public String methodToCall() { return "value"; }
}
public static class Child extends Parent {
// methodToCall() will be bridged by compiler
}
public static void main(String[] args) {
ELProcessor processor = new ELProcessor();
processor.defineBean("child", new Child());
processor.eval("child.methodToCall()");
}
}
{noformat}
> Can not call "visibility" bridged methods
> -----------------------------------------
>
> Key: WFLY-6280
> URL: https://issues.jboss.org/browse/WFLY-6280
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 9.0.2.Final, 10.0.0.Final
> Reporter: Trond G. Ziarkowski
> Assignee: Farah Juma
>
> After fix of WFLY-3456 all bridged methods are filtered which causes javax.el.MethodNotFoundException for "visibility" bridged methods.
> This has been commented by [~bodist] in WFLY-3456, but nothing has been done to fix it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 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
The goals are therefore:
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 enrypt header
h4.
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
The goals are therefore:
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}}.
> 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
> The goals are therefore:
> 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 enrypt header
> h4.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2021) Prevent messages from non-members
by Bela Ban (JIRA)
Bela Ban created JGRP-2021:
------------------------------
Summary: 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
The goals are therefore:
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}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6280) Can not call "visibility" bridged methods
by Trond G. Ziarkowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-6280?page=com.atlassian.jira.plugin.... ]
Trond G. Ziarkowski updated WFLY-6280:
--------------------------------------
Steps to Reproduce:
{noformat}
public class VisibilityBridgedMethod {
static class Parent {
public String methodToCall() { return "value"; }
}
public static class Child extends Parent {
// methodToCall() will be bridged by compiler
}
public static void main(String[] args) {
ELProcessor processor = new ELProcessor();
processor.defineBean("child", new Child());
processor.eval("child.methodToCall()");
}
}
{noformat}
was:
{{public class VisibilityBridgedMethod {
static class Parent {
public String methodToCall() { return "value"; }
}
public static class Child extends Parent {
// methodToCall() will be bridged by compiler
}
public static void main(String[] args) {
ELProcessor processor = new ELProcessor();
processor.defineBean("child", new Child());
processor.eval("child.methodToCall()");
}
}
}}
> Can not call "visibility" bridged methods
> -----------------------------------------
>
> Key: WFLY-6280
> URL: https://issues.jboss.org/browse/WFLY-6280
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 9.0.2.Final, 10.0.0.Final
> Reporter: Trond G. Ziarkowski
> Assignee: Farah Juma
>
> After fix of WFLY-3456 all bridged methods are filtered which causes javax.el.MethodNotFoundException for "visibility" bridged methods.
> This has been commented by [~bodist] in WFLY-3456, but nothing has been done to fix it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6280) Can not call "visibility" bridged methods
by Trond G. Ziarkowski (JIRA)
Trond G. Ziarkowski created WFLY-6280:
-----------------------------------------
Summary: Can not call "visibility" bridged methods
Key: WFLY-6280
URL: https://issues.jboss.org/browse/WFLY-6280
Project: WildFly
Issue Type: Bug
Components: JSF
Affects Versions: 10.0.0.Final, 9.0.2.Final
Reporter: Trond G. Ziarkowski
Assignee: Farah Juma
After fix of WFLY-3456 all bridged methods are filtered which causes javax.el.MethodNotFoundException for "visibility" bridged methods.
This has been commented by [~bodist] in WFLY-3456, but nothing has been done to fix it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the thread waiting
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.... ]
Radim Vansa resolved JGRP-1711.
-------------------------------
Fix Version/s: 3.6
(was: Future)
Resolution: Done
Changes already incorporated into DELAY.
> DELAY2: Do not keep the thread waiting
> --------------------------------------
>
> Key: JGRP-1711
> URL: https://issues.jboss.org/browse/JGRP-1711
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6
>
>
> Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period.
> As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period.
> For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers.
> Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-5916) jackson-datatype-jsr310 and jackson-datatype-jdk8 are missing
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-5916?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-5916:
------------------------------------------
Do you see a chance to include at least jackson-datatype-jsr310 in the next WildFly release?
> jackson-datatype-jsr310 and jackson-datatype-jdk8 are missing
> -------------------------------------------------------------
>
> Key: WFLY-5916
> URL: https://issues.jboss.org/browse/WFLY-5916
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 10.0.0.CR5
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
>
> WildFly doesn't provide jackson-datatype-jsr310 and jackson-datatype-jdk8 for RESTEasy. jackson-datatype-jsr310 supports the new JDK 8 time API, and jackson-datatype-jdk8 supports the new JDK 8 Optional type.
> The GAVs are:
> com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.6.3
> com.fasterxml.jackson.datatype:jackson-datatype-jdk8:2.6.3
> The latest Jackson GA version is 2.6.4. Please see also https://issues.jboss.org/browse/WFLY-5915.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months