[jira] [Created] (ARTEMIS-2790) No examples documentation in the bin archive
Domenico Bruscino created ARTEMIS-2790: -- Summary: No examples documentation in the bin archive Key: ARTEMIS-2790 URL: https://issues.apache.org/jira/browse/ARTEMIS-2790 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino The documentation of the examples is generated during release but it isn't copied in the bin archive during release because of the build order. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7491) ActiveMQ illegal occupation vulnerability
[ https://issues.apache.org/jira/browse/AMQ-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125521#comment-17125521 ] wang Jessie commented on AMQ-7491: -- I have attached the link about how to use my script. [https://github.com/wqqqy/Illegal-Occupation-on-ActiveMQ/blob/master/Illegal%20Occupation.md] The script supports sending the Header, OPEN, BEGIN seprately. Or can you share me with your script and I can test my ActiveMQ implementations? > ActiveMQ illegal occupation vulnerability > - > > Key: AMQ-7491 > URL: https://issues.apache.org/jira/browse/AMQ-7491 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 5.15.12 > Environment: We build a script used JavaScript to interact with the > broker in ActiveMQ 5.15.12. > The experiment is performed on Windows10 1903 version. >Reporter: wang Jessie >Priority: Major > Labels: security > Attachments: 1590234052205.png > > > *Description:* Two client with the same Container-Id are not allowed to > connect to the broker. When we send *two OPEN packet with same the > Container-Id*, the broker will return error and the client will close the TCP > connection. The client with this Container-Id will *never be able to connect > with the broker* unless the broker resets. This vulnerability can be > exploited by the adversary to perform the aforementioned attacks on many > Container-Id to make a huge set of clients unable to connect with the broker. > As the ActiveMQ are widely adopted by the IoT vendors, this can be a > vulnerability affected a wide range. > Following are the details. > We send *two OPEN packets with the same Container-Id 1* and we can learn from > the log A in the attached picture in the broker side that the broker returned > close packets and *the client closed this TCP connection with the broker.* > Then we build a new client to connect with the broker using the same > Container-Id 1, we can learn from the log B in the attached pictur that the > broker returned errors as the broker believe the client with Container-Id 1 > already connected. > *Suggestion for repair:* May be the state of the broker after received two > OPEN packets could be checked and the connection state of the client could be > updated when the TCP connection is closed. > > :)I hope what I found can do some help and if you want further discussion, > please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. > Thanks for spending your time on my issue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2789) Fix memory estimage for AMQP Large Message
[ https://issues.apache.org/jira/browse/ARTEMIS-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125507#comment-17125507 ] ASF subversion and git services commented on ARTEMIS-2789: -- Commit 111b551d792c35c057aa592dfdae065f7e22fd73 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=111b551 ] ARTEMIS-2789 AMQP Large Message Memory Estimate > Fix memory estimage for AMQP Large Message > -- > > Key: ARTEMIS-2789 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2789 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There's a memory estimate into AMQP Large Message that's currently returning > 0. > > Unfortunately there's no way to test this. This is just an estimate. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2789) Fix memory estimage for AMQP Large Message
[ https://issues.apache.org/jira/browse/ARTEMIS-2789?focusedWorklogId=441085=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-441085 ] ASF GitHub Bot logged work on ARTEMIS-2789: --- Author: ASF GitHub Bot Created on: 04/Jun/20 03:23 Start Date: 04/Jun/20 03:23 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3163: URL: https://github.com/apache/activemq-artemis/pull/3163 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 441085) Time Spent: 20m (was: 10m) > Fix memory estimage for AMQP Large Message > -- > > Key: ARTEMIS-2789 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2789 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > There's a memory estimate into AMQP Large Message that's currently returning > 0. > > Unfortunately there's no way to test this. This is just an estimate. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7452) java.lang.IllegalStateException: Timer already cancelled.
[
https://issues.apache.org/jira/browse/AMQ-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125442#comment-17125442
]
wangxiaoqing commented on AMQ-7452:
---
I have showed my latest error log and upload my config. please help me resolve
this problem. Thank you!
> java.lang.IllegalStateException: Timer already cancelled.
> -
>
> Key: AMQ-7452
> URL: https://issues.apache.org/jira/browse/AMQ-7452
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.3
>Reporter: wangxiaoqing
>Priority: Blocker
> Attachments: activemq.xml, docker-mq.yaml
>
>
> 2020-03-24 12:54:47,990 | ERROR | Could not accept connection from
> tcp://10.0.1.5:41212 : {} | org.apache.activemq.broker.TransportConnector |
> ActiveMQ BrokerService[localhost] Task-174422020-03-24 12:54:47,990 | ERROR |
> Could not accept connection from tcp://10.0.1.5:41212 : {} |
> org.apache.activemq.broker.TransportConnector | ActiveMQ
> BrokerService[localhost] Task-17442java.lang.IllegalStateException: Timer
> already cancelled. at java.util.Timer.sched(Timer.java:397)[:1.8.0_191] at
> java.util.Timer.schedule(Timer.java:193)[:1.8.0_191] at
> org.apache.activemq.transport.AbstractInactivityMonitor.startConnectCheckTask(AbstractInactivityMonitor.java:425)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.startConnectCheckTask(AbstractInactivityMonitor.java:400)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.InactivityMonitor.start(InactivityMonitor.java:50)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:72)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.broker.TransportConnection.start(TransportConnection.java:1066)[activemq-broker-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.broker.TransportConnector$1$1.run(TransportConnector.java:218)[activemq-broker-5.15.3.jar:5.15.3]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748)[:1.8.0_191]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-7452) java.lang.IllegalStateException: Timer already cancelled.
[
https://issues.apache.org/jira/browse/AMQ-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125441#comment-17125441
]
wangxiaoqing commented on AMQ-7452:
---
[WARN ] 2020-06-01 19:35:01,069(657751246) --> [ActiveMQ Transport:
tcp:///10.0.1.4:53714@61616]
org.apache.activemq.broker.TransportConnection.serviceException(TransportConnection.java:307):
Async error occurred: java.lang.OutOfMemoryError: unable to create new native
thread
[ERROR] 2020-06-01 20:31:57,675(661167852) --> [ActiveMQ
BrokerService[localhost] Task-18608]
org.apache.activemq.broker.TransportConnector$1.onAcceptError(TransportConnector.java:245):
Could not accept connection from null : {} [ERROR] 2020-06-01
20:31:57,675(661167852) --> [ActiveMQ BrokerService[localhost] Task-18608]
org.apache.activemq.broker.TransportConnector$1.onAcceptError(TransportConnector.java:245):
Could not accept connection from null : {} java.lang.IllegalStateException:
Timer already cancelled. at java.util.Timer.sched(Timer.java:397)[:1.8.0_191]
at java.util.Timer.schedule(Timer.java:248)[:1.8.0_191] at
org.apache.activemq.transport.mqtt.MQTTInactivityMonitor.startConnectChecker(MQTTInactivityMonitor.java:239)[activemq-mqtt-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.mqtt.MQTTTransportFilter.start(MQTTTransportFilter.java:155)[activemq-mqtt-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.mqtt.MQTTInactivityMonitor.start(MQTTInactivityMonitor.java:148)[activemq-mqtt-5.15.3.jar:5.15.3]
at
org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)[activemq-client-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.TransportConnection.start(TransportConnection.java:1066)[activemq-broker-5.15.3.jar:5.15.3]
at
org.apache.activemq.broker.TransportConnector$1$1.run(TransportConnector.java:218)[activemq-broker-5.15.3.jar:5.15.3]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_191]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_191]
> java.lang.IllegalStateException: Timer already cancelled.
> -
>
> Key: AMQ-7452
> URL: https://issues.apache.org/jira/browse/AMQ-7452
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.3
>Reporter: wangxiaoqing
>Priority: Blocker
> Attachments: activemq.xml, docker-mq.yaml
>
>
> 2020-03-24 12:54:47,990 | ERROR | Could not accept connection from
> tcp://10.0.1.5:41212 : {} | org.apache.activemq.broker.TransportConnector |
> ActiveMQ BrokerService[localhost] Task-174422020-03-24 12:54:47,990 | ERROR |
> Could not accept connection from tcp://10.0.1.5:41212 : {} |
> org.apache.activemq.broker.TransportConnector | ActiveMQ
> BrokerService[localhost] Task-17442java.lang.IllegalStateException: Timer
> already cancelled. at java.util.Timer.sched(Timer.java:397)[:1.8.0_191] at
> java.util.Timer.schedule(Timer.java:193)[:1.8.0_191] at
> org.apache.activemq.transport.AbstractInactivityMonitor.startConnectCheckTask(AbstractInactivityMonitor.java:425)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.startConnectCheckTask(AbstractInactivityMonitor.java:400)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.InactivityMonitor.start(InactivityMonitor.java:50)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:72)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.broker.TransportConnection.start(TransportConnection.java:1066)[activemq-broker-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.broker.TransportConnector$1$1.run(TransportConnector.java:218)[activemq-broker-5.15.3.jar:5.15.3]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748)[:1.8.0_191]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AMQ-7452) java.lang.IllegalStateException: Timer already cancelled.
[
https://issues.apache.org/jira/browse/AMQ-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
wangxiaoqing updated AMQ-7452:
--
Attachment: activemq.xml
> java.lang.IllegalStateException: Timer already cancelled.
> -
>
> Key: AMQ-7452
> URL: https://issues.apache.org/jira/browse/AMQ-7452
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.3
>Reporter: wangxiaoqing
>Priority: Blocker
> Attachments: activemq.xml, docker-mq.yaml
>
>
> 2020-03-24 12:54:47,990 | ERROR | Could not accept connection from
> tcp://10.0.1.5:41212 : {} | org.apache.activemq.broker.TransportConnector |
> ActiveMQ BrokerService[localhost] Task-174422020-03-24 12:54:47,990 | ERROR |
> Could not accept connection from tcp://10.0.1.5:41212 : {} |
> org.apache.activemq.broker.TransportConnector | ActiveMQ
> BrokerService[localhost] Task-17442java.lang.IllegalStateException: Timer
> already cancelled. at java.util.Timer.sched(Timer.java:397)[:1.8.0_191] at
> java.util.Timer.schedule(Timer.java:193)[:1.8.0_191] at
> org.apache.activemq.transport.AbstractInactivityMonitor.startConnectCheckTask(AbstractInactivityMonitor.java:425)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.startConnectCheckTask(AbstractInactivityMonitor.java:400)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.InactivityMonitor.start(InactivityMonitor.java:50)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:72)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.broker.TransportConnection.start(TransportConnection.java:1066)[activemq-broker-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.broker.TransportConnector$1$1.run(TransportConnector.java:218)[activemq-broker-5.15.3.jar:5.15.3]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748)[:1.8.0_191]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (AMQ-7452) java.lang.IllegalStateException: Timer already cancelled.
[
https://issues.apache.org/jira/browse/AMQ-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
wangxiaoqing updated AMQ-7452:
--
Attachment: docker-mq.yaml
> java.lang.IllegalStateException: Timer already cancelled.
> -
>
> Key: AMQ-7452
> URL: https://issues.apache.org/jira/browse/AMQ-7452
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.3
>Reporter: wangxiaoqing
>Priority: Blocker
> Attachments: activemq.xml, docker-mq.yaml
>
>
> 2020-03-24 12:54:47,990 | ERROR | Could not accept connection from
> tcp://10.0.1.5:41212 : {} | org.apache.activemq.broker.TransportConnector |
> ActiveMQ BrokerService[localhost] Task-174422020-03-24 12:54:47,990 | ERROR |
> Could not accept connection from tcp://10.0.1.5:41212 : {} |
> org.apache.activemq.broker.TransportConnector | ActiveMQ
> BrokerService[localhost] Task-17442java.lang.IllegalStateException: Timer
> already cancelled. at java.util.Timer.sched(Timer.java:397)[:1.8.0_191] at
> java.util.Timer.schedule(Timer.java:193)[:1.8.0_191] at
> org.apache.activemq.transport.AbstractInactivityMonitor.startConnectCheckTask(AbstractInactivityMonitor.java:425)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.startConnectCheckTask(AbstractInactivityMonitor.java:400)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.InactivityMonitor.start(InactivityMonitor.java:50)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:72)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)[activemq-client-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.broker.TransportConnection.start(TransportConnection.java:1066)[activemq-broker-5.15.3.jar:5.15.3]
> at
> org.apache.activemq.broker.TransportConnector$1$1.run(TransportConnector.java:218)[activemq-broker-5.15.3.jar:5.15.3]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748)[:1.8.0_191]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-7491) ActiveMQ illegal occupation vulnerability
[ https://issues.apache.org/jira/browse/AMQ-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125303#comment-17125303 ] wang Jessie commented on AMQ-7491: -- I used the default setting that transport.useInactivityMonitor=true. Only sending a OPEN packet with the a container ID to the broker when a client with the same container ID have opened the channel but didn't begin the session can cause this problem. Other exceptions that caused the client offline are noticed by the inactivity monitor. > ActiveMQ illegal occupation vulnerability > - > > Key: AMQ-7491 > URL: https://issues.apache.org/jira/browse/AMQ-7491 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 5.15.12 > Environment: We build a script used JavaScript to interact with the > broker in ActiveMQ 5.15.12. > The experiment is performed on Windows10 1903 version. >Reporter: wang Jessie >Priority: Major > Labels: security > Attachments: 1590234052205.png > > > *Description:* Two client with the same Container-Id are not allowed to > connect to the broker. When we send *two OPEN packet with same the > Container-Id*, the broker will return error and the client will close the TCP > connection. The client with this Container-Id will *never be able to connect > with the broker* unless the broker resets. This vulnerability can be > exploited by the adversary to perform the aforementioned attacks on many > Container-Id to make a huge set of clients unable to connect with the broker. > As the ActiveMQ are widely adopted by the IoT vendors, this can be a > vulnerability affected a wide range. > Following are the details. > We send *two OPEN packets with the same Container-Id 1* and we can learn from > the log A in the attached picture in the broker side that the broker returned > close packets and *the client closed this TCP connection with the broker.* > Then we build a new client to connect with the broker using the same > Container-Id 1, we can learn from the log B in the attached pictur that the > broker returned errors as the broker believe the client with Container-Id 1 > already connected. > *Suggestion for repair:* May be the state of the broker after received two > OPEN packets could be checked and the connection state of the client could be > updated when the TCP connection is closed. > > :)I hope what I found can do some help and if you want further discussion, > please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. > Thanks for spending your time on my issue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2785) io.netty.util.internal.OutOfDirectMemoryError during uncompress
[ https://issues.apache.org/jira/browse/ARTEMIS-2785?focusedWorklogId=440973=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-440973 ] ASF GitHub Bot logged work on ARTEMIS-2785: --- Author: ASF GitHub Bot Created on: 03/Jun/20 20:33 Start Date: 03/Jun/20 20:33 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on pull request #3154: URL: https://github.com/apache/activemq-artemis/pull/3154#issuecomment-638446243 @clebertsuconic we have a feature needed just finishing it up. As had a prod issue. Can you hold any release for a day or two so i can get it in please This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 440973) Time Spent: 2h 20m (was: 2h 10m) > io.netty.util.internal.OutOfDirectMemoryError during uncompress > --- > > Key: ARTEMIS-2785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2785 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.12.0 > Environment: uname -a > Linux 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > java version "1.8.0_211" >Reporter: Tarek Hammoud >Assignee: Clebert Suconic >Priority: Major > Attachments: ArtemisStressTest.java > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, > It appears that there is memory leak during decompression. Memory used per > PlatformDependent keeps creeping up until the OutOfDirectMemoryError is > thrown. Attached is a test program that recreates it. You can see the memory > creeping up until it runs out. [^ArtemisStressTest.java] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7491) ActiveMQ illegal occupation vulnerability
[ https://issues.apache.org/jira/browse/AMQ-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125290#comment-17125290 ] Timothy A. Bish commented on AMQ-7491: -- The client connection is checked by the inactivity monitor to ensure that it will not remain open forever in the case of a drop at the client end. I've tested this and can find no issues with that validation, if you've configured that off in your broker then yes you could have issues with clients dropping and not being noticed but that'd be due to configuration. The test script is far to complicated and was not functional for me so I've tested using modifications of the existing client tests which also check various aspects of this so you need to create a more simpler test script that can provoke the issue you think you are seeing for an outside observer to validate. > ActiveMQ illegal occupation vulnerability > - > > Key: AMQ-7491 > URL: https://issues.apache.org/jira/browse/AMQ-7491 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 5.15.12 > Environment: We build a script used JavaScript to interact with the > broker in ActiveMQ 5.15.12. > The experiment is performed on Windows10 1903 version. >Reporter: wang Jessie >Priority: Major > Labels: security > Attachments: 1590234052205.png > > > *Description:* Two client with the same Container-Id are not allowed to > connect to the broker. When we send *two OPEN packet with same the > Container-Id*, the broker will return error and the client will close the TCP > connection. The client with this Container-Id will *never be able to connect > with the broker* unless the broker resets. This vulnerability can be > exploited by the adversary to perform the aforementioned attacks on many > Container-Id to make a huge set of clients unable to connect with the broker. > As the ActiveMQ are widely adopted by the IoT vendors, this can be a > vulnerability affected a wide range. > Following are the details. > We send *two OPEN packets with the same Container-Id 1* and we can learn from > the log A in the attached picture in the broker side that the broker returned > close packets and *the client closed this TCP connection with the broker.* > Then we build a new client to connect with the broker using the same > Container-Id 1, we can learn from the log B in the attached pictur that the > broker returned errors as the broker believe the client with Container-Id 1 > already connected. > *Suggestion for repair:* May be the state of the broker after received two > OPEN packets could be checked and the connection state of the client could be > updated when the TCP connection is closed. > > :)I hope what I found can do some help and if you want further discussion, > please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. > Thanks for spending your time on my issue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-7491) ActiveMQ illegal occupation vulnerability
[ https://issues.apache.org/jira/browse/AMQ-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] wang Jessie updated AMQ-7491: - Description: *Description:* Two client with the same Container-Id are not allowed to connect to the broker. When we send *two OPEN packet with same the Container-Id*, the broker will return error and the client will close the TCP connection. The client with this Container-Id will *never be able to connect with the broker* unless the broker resets. This vulnerability can be exploited by the adversary to perform the aforementioned attacks on many Container-Id to make a huge set of clients unable to connect with the broker. As the ActiveMQ are widely adopted by the IoT vendors, this can be a vulnerability affected a wide range. Following are the details. We send *two OPEN packets with the same Container-Id 1* and we can learn from the log A in the attached picture in the broker side that the broker returned close packets and *the client closed this TCP connection with the broker.* Then we build a new client to connect with the broker using the same Container-Id 1, we can learn from the log B in the attached pictur that the broker returned errors as the broker believe the client with Container-Id 1 already connected. *Suggestion for repair:* May be the state of the broker after received two OPEN packets could be checked and the connection state of the client could be updated when the TCP connection is closed. :)I hope what I found can do some help and if you want further discussion, please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. Thanks for spending your time on my issue. was: *Description:* Two client with the same Container-Id are not allowed to connect to the broker. When we send *two OPEN packet with same the Container-Id*, the broker will return error and the client will close the TCP connection. The client with this Container-Id will *never be able to connect with the broker* unless the broker resets. This vulnerability can be exploited by the adversary to perform the aforementioned attacks on many Container-Id to make a huge set of clients unable to connect with the broker. As the ActiveMQ are widely adopted by the IoT vendors, this can be a vulnerability affected a wide range. Following are the details. We send *two OPEN packets with the same Container-Id 1* and we can learn from the log A in the attached picture in the broker side that the broker returned close packets and the client closed this TCP connection with the broker. Then we build a new client to connect with the broker using the same Container-Id 1, we can learn from the log B in the attached pictur that the broker returned errors as the broker believe the client with Container-Id 1 already connected. *Suggestion for repair:* May be the state of the broker after received two OPEN packets could be checked and the connection state of the client could be updated when the TCP connection is closed. :)I hope what I found can do some help and if you want further discussion, please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. Thanks for spending your time on my issue. > ActiveMQ illegal occupation vulnerability > - > > Key: AMQ-7491 > URL: https://issues.apache.org/jira/browse/AMQ-7491 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 5.15.12 > Environment: We build a script used JavaScript to interact with the > broker in ActiveMQ 5.15.12. > The experiment is performed on Windows10 1903 version. >Reporter: wang Jessie >Priority: Major > Labels: security > Attachments: 1590234052205.png > > > *Description:* Two client with the same Container-Id are not allowed to > connect to the broker. When we send *two OPEN packet with same the > Container-Id*, the broker will return error and the client will close the TCP > connection. The client with this Container-Id will *never be able to connect > with the broker* unless the broker resets. This vulnerability can be > exploited by the adversary to perform the aforementioned attacks on many > Container-Id to make a huge set of clients unable to connect with the broker. > As the ActiveMQ are widely adopted by the IoT vendors, this can be a > vulnerability affected a wide range. > Following are the details. > We send *two OPEN packets with the same Container-Id 1* and we can learn from > the log A in the attached picture in the broker side that the broker returned > close packets and *the client closed this TCP connection with the broker.* > Then we build a new client to connect with the broker using the same > Container-Id 1, we can learn from the log B in the attached pictur that the > broker returned errors as
[jira] [Comment Edited] (AMQ-7491) ActiveMQ illegal occupation vulnerability
[ https://issues.apache.org/jira/browse/AMQ-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125283#comment-17125283 ] wang Jessie edited comment on AMQ-7491 at 6/3/20, 8:17 PM: --- It is true that the that only one client connection with the same ID can be active at any time. However, the former client actually close its connection, the ActiveMQ belives the client is still connected. The client want to reconnect to the server but will never succeed because only one client connection with the same ID can be active at any time. I believe the ActiveMQ should delete the connection state of the client when the client has closed its connection. As the log in my attached picture, the client from tcp://127.0.0.1:63566 is already closed. !1590234052205.png! was (Author: wqy): It is true that the that only one client connection with the same ID can be active at any time. However, the former client actually close its connection, the ActiveMQ belives the client is still connected. The client want to reconnect to the server but will never succeed. As the log in my attached picture, the client from tcp://127.0.0.1:63566 is already closed. !1590234052205.png! > ActiveMQ illegal occupation vulnerability > - > > Key: AMQ-7491 > URL: https://issues.apache.org/jira/browse/AMQ-7491 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 5.15.12 > Environment: We build a script used JavaScript to interact with the > broker in ActiveMQ 5.15.12. > The experiment is performed on Windows10 1903 version. >Reporter: wang Jessie >Priority: Major > Labels: security > Attachments: 1590234052205.png > > > *Description:* Two client with the same Container-Id are not allowed to > connect to the broker. When we send *two OPEN packet with same the > Container-Id*, the broker will return error and the client will close the TCP > connection. The client with this Container-Id will *never be able to connect > with the broker* unless the broker resets. This vulnerability can be > exploited by the adversary to perform the aforementioned attacks on many > Container-Id to make a huge set of clients unable to connect with the broker. > As the ActiveMQ are widely adopted by the IoT vendors, this can be a > vulnerability affected a wide range. > Following are the details. > We send *two OPEN packets with the same Container-Id 1* and we can learn from > the log A in the attached picture in the broker side that the broker returned > close packets and the client closed this TCP connection with the broker. > Then we build a new client to connect with the broker using the same > Container-Id 1, we can learn from the log B in the attached pictur that the > broker returned errors as the broker believe the client with Container-Id 1 > already connected. > *Suggestion for repair:* May be the state of the broker after received two > OPEN packets could be checked and the connection state of the client could be > updated when the TCP connection is closed. > > :)I hope what I found can do some help and if you want further discussion, > please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. > Thanks for spending your time on my issue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2785) io.netty.util.internal.OutOfDirectMemoryError during uncompress
[ https://issues.apache.org/jira/browse/ARTEMIS-2785?focusedWorklogId=440963=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-440963 ] ASF GitHub Bot logged work on ARTEMIS-2785: --- Author: ASF GitHub Bot Created on: 03/Jun/20 20:16 Start Date: 03/Jun/20 20:16 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #3154: URL: https://github.com/apache/activemq-artemis/pull/3154#issuecomment-638437845 @sebthom I actually am... although I'm not branching 2.13.. I will release from master.. and if there are features it promotes the number to 2.14.0... Since there's nothing breaking any compatibility, I'm considering just releasing from master. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 440963) Time Spent: 2h 10m (was: 2h) > io.netty.util.internal.OutOfDirectMemoryError during uncompress > --- > > Key: ARTEMIS-2785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2785 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.12.0 > Environment: uname -a > Linux 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > java version "1.8.0_211" >Reporter: Tarek Hammoud >Assignee: Clebert Suconic >Priority: Major > Attachments: ArtemisStressTest.java > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Hi, > It appears that there is memory leak during decompression. Memory used per > PlatformDependent keeps creeping up until the OutOfDirectMemoryError is > thrown. Attached is a test program that recreates it. You can see the memory > creeping up until it runs out. [^ArtemisStressTest.java] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7491) ActiveMQ illegal occupation vulnerability
[ https://issues.apache.org/jira/browse/AMQ-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125283#comment-17125283 ] wang Jessie edited comment on AMQ-7491 at 6/3/20, 8:14 PM: --- It is true that the that only one client connection with the same ID can be active at any time. However, the former client actually close its connection, the ActiveMQ belives the client is still connected. The client want to reconnect to the server but will never succeed. As the log in my attached picture, the client from tcp://127.0.0.1:63566 is already closed. !1590234052205.png! was (Author: wqy): It is true that the that only one client connection with the same ID can be active at any time. However, the former client actually close its connection, the ActiveMQ belives the client is still connected. > ActiveMQ illegal occupation vulnerability > - > > Key: AMQ-7491 > URL: https://issues.apache.org/jira/browse/AMQ-7491 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 5.15.12 > Environment: We build a script used JavaScript to interact with the > broker in ActiveMQ 5.15.12. > The experiment is performed on Windows10 1903 version. >Reporter: wang Jessie >Priority: Major > Labels: security > Attachments: 1590234052205.png > > > *Description:* Two client with the same Container-Id are not allowed to > connect to the broker. When we send *two OPEN packet with same the > Container-Id*, the broker will return error and the client will close the TCP > connection. The client with this Container-Id will *never be able to connect > with the broker* unless the broker resets. This vulnerability can be > exploited by the adversary to perform the aforementioned attacks on many > Container-Id to make a huge set of clients unable to connect with the broker. > As the ActiveMQ are widely adopted by the IoT vendors, this can be a > vulnerability affected a wide range. > Following are the details. > We send *two OPEN packets with the same Container-Id 1* and we can learn from > the log A in the attached picture in the broker side that the broker returned > close packets and the client closed this TCP connection with the broker. > Then we build a new client to connect with the broker using the same > Container-Id 1, we can learn from the log B in the attached pictur that the > broker returned errors as the broker believe the client with Container-Id 1 > already connected. > *Suggestion for repair:* May be the state of the broker after received two > OPEN packets could be checked and the connection state of the client could be > updated when the TCP connection is closed. > > :)I hope what I found can do some help and if you want further discussion, > please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. > Thanks for spending your time on my issue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7491) ActiveMQ illegal occupation vulnerability
[ https://issues.apache.org/jira/browse/AMQ-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125283#comment-17125283 ] wang Jessie commented on AMQ-7491: -- It is true that the that only one client connection with the same ID can be active at any time. However, the former client actually close its connection, the ActiveMQ belives the client is still connected. > ActiveMQ illegal occupation vulnerability > - > > Key: AMQ-7491 > URL: https://issues.apache.org/jira/browse/AMQ-7491 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 5.15.12 > Environment: We build a script used JavaScript to interact with the > broker in ActiveMQ 5.15.12. > The experiment is performed on Windows10 1903 version. >Reporter: wang Jessie >Priority: Major > Labels: security > Attachments: 1590234052205.png > > > *Description:* Two client with the same Container-Id are not allowed to > connect to the broker. When we send *two OPEN packet with same the > Container-Id*, the broker will return error and the client will close the TCP > connection. The client with this Container-Id will *never be able to connect > with the broker* unless the broker resets. This vulnerability can be > exploited by the adversary to perform the aforementioned attacks on many > Container-Id to make a huge set of clients unable to connect with the broker. > As the ActiveMQ are widely adopted by the IoT vendors, this can be a > vulnerability affected a wide range. > Following are the details. > We send *two OPEN packets with the same Container-Id 1* and we can learn from > the log A in the attached picture in the broker side that the broker returned > close packets and the client closed this TCP connection with the broker. > Then we build a new client to connect with the broker using the same > Container-Id 1, we can learn from the log B in the attached pictur that the > broker returned errors as the broker believe the client with Container-Id 1 > already connected. > *Suggestion for repair:* May be the state of the broker after received two > OPEN packets could be checked and the connection state of the client could be > updated when the TCP connection is closed. > > :)I hope what I found can do some help and if you want further discussion, > please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. > Thanks for spending your time on my issue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2785) io.netty.util.internal.OutOfDirectMemoryError during uncompress
[ https://issues.apache.org/jira/browse/ARTEMIS-2785?focusedWorklogId=440960=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-440960 ] ASF GitHub Bot logged work on ARTEMIS-2785: --- Author: ASF GitHub Bot Created on: 03/Jun/20 20:10 Start Date: 03/Jun/20 20:10 Worklog Time Spent: 10m Work Description: sebthom commented on pull request #3154: URL: https://github.com/apache/activemq-artemis/pull/3154#issuecomment-638435326 @clebertsuconic Thanks for the update. I think then we are safe in our scenario to upgrade. We did not experience a memory leak so far. Are you still considering a 2.13.1 release? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 440960) Time Spent: 2h (was: 1h 50m) > io.netty.util.internal.OutOfDirectMemoryError during uncompress > --- > > Key: ARTEMIS-2785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2785 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.12.0 > Environment: uname -a > Linux 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > java version "1.8.0_211" >Reporter: Tarek Hammoud >Assignee: Clebert Suconic >Priority: Major > Attachments: ArtemisStressTest.java > > Time Spent: 2h > Remaining Estimate: 0h > > Hi, > It appears that there is memory leak during decompression. Memory used per > PlatformDependent keeps creeping up until the OutOfDirectMemoryError is > thrown. Attached is a test program that recreates it. You can see the memory > creeping up until it runs out. [^ArtemisStressTest.java] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2785) io.netty.util.internal.OutOfDirectMemoryError during uncompress
[ https://issues.apache.org/jira/browse/ARTEMIS-2785?focusedWorklogId=440955=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-440955 ] ASF GitHub Bot logged work on ARTEMIS-2785: --- Author: ASF GitHub Bot Created on: 03/Jun/20 20:05 Start Date: 03/Jun/20 20:05 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #3154: URL: https://github.com/apache/activemq-artemis/pull/3154#issuecomment-638432610 @sebthom this has been an issue since at least 2.6.0, possibly longer as I believe I copied the code from somewhere else when I committed e86acd4824d3a94d124693fbd7887a1f1b9b072c This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 440955) Time Spent: 1h 50m (was: 1h 40m) > io.netty.util.internal.OutOfDirectMemoryError during uncompress > --- > > Key: ARTEMIS-2785 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2785 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.12.0 > Environment: uname -a > Linux 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux > java version "1.8.0_211" >Reporter: Tarek Hammoud >Assignee: Clebert Suconic >Priority: Major > Attachments: ArtemisStressTest.java > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Hi, > It appears that there is memory leak during decompression. Memory used per > PlatformDependent keeps creeping up until the OutOfDirectMemoryError is > thrown. Attached is a test program that recreates it. You can see the memory > creeping up until it runs out. [^ArtemisStressTest.java] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2789) Fix memory estimage for AMQP Large Message
[ https://issues.apache.org/jira/browse/ARTEMIS-2789?focusedWorklogId=440948=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-440948 ] ASF GitHub Bot logged work on ARTEMIS-2789: --- Author: ASF GitHub Bot Created on: 03/Jun/20 19:50 Start Date: 03/Jun/20 19:50 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request #3163: URL: https://github.com/apache/activemq-artemis/pull/3163 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 440948) Remaining Estimate: 0h Time Spent: 10m > Fix memory estimage for AMQP Large Message > -- > > Key: ARTEMIS-2789 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2789 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There's a memory estimate into AMQP Large Message that's currently returning > 0. > > Unfortunately there's no way to test this. This is just an estimate. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2789) Fix memory estimage for AMQP Large Message
Clebert Suconic created ARTEMIS-2789: Summary: Fix memory estimage for AMQP Large Message Key: ARTEMIS-2789 URL: https://issues.apache.org/jira/browse/ARTEMIS-2789 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Clebert Suconic There's a memory estimate into AMQP Large Message that's currently returning 0. Unfortunately there's no way to test this. This is just an estimate. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2751) Call to AMQPMessage.setValidatedUserID does nothing
[
https://issues.apache.org/jira/browse/ARTEMIS-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125174#comment-17125174
]
Justin Bertram commented on ARTEMIS-2751:
-
This was discussed on the dev mailing list, but I wanted to include an
explanation here for those who don't have access to that list...
In short, I think AMQP messages will require a different solution than core
messages due to the fact that properties in an AMQP message are immutable (as
mentioned previously by Robbie). Also, AMQP has some built in support for these
semantics.
Section 3.2.4 of the [AMQP 1.0
specification|http://www.amqp.org/sites/amqp.org/files/amqp.pdf] defines the
{{user-id}} message property and defines it as:
bq. The identity of the user responsible for producing the Message. The client
sets this value, and it MAY be authenticated by intermediaries.
My recommendation would be to use this field when producing messages and then
implement the
{{org.apache.activemq.artemis.core.server.plugin.ActiveMQServerMessagePlugin#beforeSend()}}
method in a plugin on the broker which checks this property against the value
returned by
{{org.apache.activemq.artemis.core.server.ServerSession#getValidatedUser()}}.
See [the
documentation|http://activemq.apache.org/components/artemis/documentation/latest/broker-plugins.html]
for more details on implementing plugins.
> Call to AMQPMessage.setValidatedUserID does nothing
> ---
>
> Key: ARTEMIS-2751
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2751
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.12.0
>Reporter: Viktor Kolomeyko
>Priority: Major
>
> Method {{setValidatedUserID}} is not overridden for {{AMQPMessage}} class -
> therefore it calls parent implementation which does nothing.
> On the other hand:
> {{org.apache.activemq.artemis.core.message.impl.CoreMessage#setValidatedUserID}}
> does the right thing and correctly retains validated user information as
> supplied by
> {{org.apache.activemq.artemis.core.server.impl.ServerSessionImpl#doSend}}
> This deficiency prevents from reading
> {{org.apache.activemq.artemis.api.core.Message#HDR_VALIDATED_USER}} attribute
> when it is received via AMQP protocol.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2768) Negative AddressSize in JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125063#comment-17125063 ] Tarek Hammoud commented on ARTEMIS-2768: I think that the "shared" Message reference count in the same message destined to two different queues is causing this size mismatch. MessageId=35 never added the full message size as that was done by the wild card. Yet the down logic has a zero check that takes the down the size and the reference size. It looks like these address sizes do not work for when you have a wild card & a regular full topic. > Negative AddressSize in JMX > --- > > Key: ARTEMIS-2768 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2768 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.11.0, 2.12.0 >Reporter: Tarek Hammoud >Priority: Major > Attachments: TestWildCard.java > > > Hello, > I see negative address size in JMX. This happens when there are two > consumers. One listening on the full topic name. The other listening on the > wild card topic. I can easily reproduce with this. [^TestWildCard.java] > ^Broker shows:^ > ^2020-05-17 09:24:34,826 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-152.^ > ^2020-05-17 09:24:34,827 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-88.^ > ^2020-05-17 09:24:34,828 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-944.^ > ^2020-05-17 09:24:34,828 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-1,800.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-1,736.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-2,592.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-3,448.^ > ^2020-05-17 09:24:34,830 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-4,304.^ > ^2020-05-17 09:24:34,830 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-5,160.^ > ^2020-05-17 09:24:34,830 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-5,096.^ > ^2020-05-17 09:24:34,831 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-5,952.^ > ^2020-05-17 09:24:34,831 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,016.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,080.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,016.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-6,872.^ > ^2020-05-17 09:24:34,832 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-7,728.^ > ^2020-05-17 09:24:34,833 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-8,584.^ > ^2020-05-17 09:24:34,833 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-8,520.^ > ^2020-05-17 09:24:34,833 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-9,376.^ > ^2020-05-17 09:24:34,834 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-10,232.^ > ^2020-05-17 09:24:34,834 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar
[jira] [Commented] (ARTEMIS-2768) Negative AddressSize in JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125052#comment-17125052 ] Tarek Hammoud commented on ARTEMIS-2768: Added some debug to PagingStoreImpl: >From PagineStoreImpl.java The Ups: Thread-1 MessageId=35. RefUp:global.#. Count=1 Thread-1 . addSize:global.#. Size=856. New Size=856 Thread-1 MessageId=35. RefUp:global.topic.FooBar. Count=2 Thread-1 . addSize:global.topic.FooBar. Size=64. New Size=64 Thread-1 MessageId=36. RefUp:global.#. Count=1 Thread-1 . addSize:global.#. Size=856. New Size=1712 Thread-1 MessageId=36. RefUp:global.topic.FooBar. Count=2 Thread-1 . addSize:global.topic.FooBar. Size=64. New Size=128 Thread-1 MessageId=37. RefUp:global.#. Count=1 Thread-1 . addSize:global.#. Size=856. New Size=2568 Thread-1 MessageId=37. RefUp:global.topic.FooBar. Count=2 Thread-1 . addSize:global.topic.FooBar. Size=64. New Size=192 Thread-1 MessageId=38. RefUp:global.#. Count=1 Thread-1 . addSize:global.#. Size=856. New Size=3424 Thread-1 MessageId=38. RefUp:global.topic.FooBar. Count=2 Thread-1 . addSize:global.topic.FooBar. Size=64. New Size=256 Thread-1 MessageId=39. RefUp:global.#. Count=1 Thread-1 . addSize:global.#. Size=856. New Size=4280 Thread-1 MessageId=39. RefUp:global.topic.FooBar. Count=2 Thread-1 . addSize:global.topic.FooBar. Size=64. New Size=320 Thread-1 MessageId=40. RefUp:global.#. Count=1 Thread-1 . addSize:global.#. Size=856. New Size=5136 Thread-1 MessageId=40. RefUp:global.topic.FooBar. Count=2 Thread-1 . addSize:global.topic.FooBar. Size=64. New Size=384 Thread-1 MessageId=41. RefUp:global.#. Count=1 Thread-1 . addSize:global.#. Size=856. New Size=5992 Thread-1 MessageId=41. RefUp:global.topic.FooBar. Count=2 Thread-1 . addSize:global.topic.FooBar. Size=64. New Size=448 Thread-1 MessageId=42. RefUp:global.#. Count=1 Thread-1 . addSize:global.#. Size=856. New Size=6848 Thread-1 MessageId=42. RefUp:global.topic.FooBar. Count=2 Thread-1 . addSize:global.topic.FooBar. Size=64. New Size=512 Thread-1 MessageId=45. RefUp:global.#. Count=1 Thread-1 . addSize:global.#. Size=856. New Size=7704 Thread-1 MessageId=45. RefUp:global.topic.FooBar. Count=2 Thread-1 . addSize:global.topic.FooBar. Size=64. New Size=576 Thread-1 MessageId=46. RefUp:global.#. Count=1 Thread-1 . addSize:global.#. Size=856. New Size=8560 Thread-1 MessageId=46. RefUp:global.topic.FooBar. Count=2 Thread-1 . addSize:global.topic.FooBar. Size=64. New Size=640 The Downs: == Thread-0 MessageId=35. RefDown:global.#. Count=1 Thread-0 . addSize:global.#. Size=-64. New Size=8496 Thread-0 MessageId=36. RefDown:global.#. Count=1 Thread-0 . addSize:global.#. Size=-64. New Size=8432 Thread-0 MessageId=37. RefDown:global.#. Count=1 Thread-0 . addSize:global.#. Size=-64. New Size=8368 Thread-0 MessageId=38. RefDown:global.#. Count=1 Thread-0 . addSize:global.#. Size=-64. New Size=8304 Thread-0 MessageId=39. RefDown:global.#. Count=1 Thread-0 . addSize:global.#. Size=-64. New Size=8240 Thread-2 MessageId=35. RefDown:global.topic.FooBar. Count=0 Thread-2 . addSize:global.topic.FooBar. Size=-856. New Size=-216 *2020-06-03 09:08:20,772 Thread-2 WARN [org.apache.activemq.artemis.core.server] AMQ14: Destination global.topic.FooBar has an inconsistent and negative address size=-216.* > Negative AddressSize in JMX > --- > > Key: ARTEMIS-2768 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2768 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.11.0, 2.12.0 >Reporter: Tarek Hammoud >Priority: Major > Attachments: TestWildCard.java > > > Hello, > I see negative address size in JMX. This happens when there are two > consumers. One listening on the full topic name. The other listening on the > wild card topic. I can easily reproduce with this. [^TestWildCard.java] > ^Broker shows:^ > ^2020-05-17 09:24:34,826 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-152.^ > ^2020-05-17 09:24:34,827 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-88.^ > ^2020-05-17 09:24:34,828 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-944.^ > ^2020-05-17 09:24:34,828 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-1,800.^ > ^2020-05-17 09:24:34,829 WARN [org.apache.activemq.artemis.core.server] > AMQ14: Destination global.topic.FooBar has an inconsistent and negative > address size=-1,736.^ >
[jira] [Updated] (AMQ-7491) ActiveMQ illegal occupation vulnerability
[ https://issues.apache.org/jira/browse/AMQ-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy A. Bish updated AMQ-7491: - Priority: Major (was: Blocker) > ActiveMQ illegal occupation vulnerability > - > > Key: AMQ-7491 > URL: https://issues.apache.org/jira/browse/AMQ-7491 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 5.15.12 > Environment: We build a script used JavaScript to interact with the > broker in ActiveMQ 5.15.12. > The experiment is performed on Windows10 1903 version. >Reporter: wang Jessie >Priority: Major > Labels: security > Attachments: 1590234052205.png > > > *Description:* Two client with the same Container-Id are not allowed to > connect to the broker. When we send *two OPEN packet with same the > Container-Id*, the broker will return error and the client will close the TCP > connection. The client with this Container-Id will *never be able to connect > with the broker* unless the broker resets. This vulnerability can be > exploited by the adversary to perform the aforementioned attacks on many > Container-Id to make a huge set of clients unable to connect with the broker. > As the ActiveMQ are widely adopted by the IoT vendors, this can be a > vulnerability affected a wide range. > Following are the details. > We send *two OPEN packets with the same Container-Id 1* and we can learn from > the log A in the attached picture in the broker side that the broker returned > close packets and the client closed this TCP connection with the broker. > Then we build a new client to connect with the broker using the same > Container-Id 1, we can learn from the log B in the attached pictur that the > broker returned errors as the broker believe the client with Container-Id 1 > already connected. > *Suggestion for repair:* May be the state of the broker after received two > OPEN packets could be checked and the connection state of the client could be > updated when the TCP connection is closed. > > :)I hope what I found can do some help and if you want further discussion, > please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. > Thanks for spending your time on my issue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7491) ActiveMQ illegal occupation vulnerability
[ https://issues.apache.org/jira/browse/AMQ-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125035#comment-17125035 ] Timothy A. Bish commented on AMQ-7491: -- Could not reproduce any unexpected behaviour from the broker. The container ID is treated as the client ID in the same manner as an OpenWire JMS client and as such only one client connection with the same ID can be active at any given time. > ActiveMQ illegal occupation vulnerability > - > > Key: AMQ-7491 > URL: https://issues.apache.org/jira/browse/AMQ-7491 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 5.15.12 > Environment: We build a script used JavaScript to interact with the > broker in ActiveMQ 5.15.12. > The experiment is performed on Windows10 1903 version. >Reporter: wang Jessie >Priority: Major > Labels: security > Attachments: 1590234052205.png > > > *Description:* Two client with the same Container-Id are not allowed to > connect to the broker. When we send *two OPEN packet with same the > Container-Id*, the broker will return error and the client will close the TCP > connection. The client with this Container-Id will *never be able to connect > with the broker* unless the broker resets. This vulnerability can be > exploited by the adversary to perform the aforementioned attacks on many > Container-Id to make a huge set of clients unable to connect with the broker. > As the ActiveMQ are widely adopted by the IoT vendors, this can be a > vulnerability affected a wide range. > Following are the details. > We send *two OPEN packets with the same Container-Id 1* and we can learn from > the log A in the attached picture in the broker side that the broker returned > close packets and the client closed this TCP connection with the broker. > Then we build a new client to connect with the broker using the same > Container-Id 1, we can learn from the log B in the attached pictur that the > broker returned errors as the broker believe the client with Container-Id 1 > already connected. > *Suggestion for repair:* May be the state of the broker after received two > OPEN packets could be checked and the connection state of the client could be > updated when the TCP connection is closed. > > :)I hope what I found can do some help and if you want further discussion, > please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. > Thanks for spending your time on my issue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-2788) OpenWire producerId leak in session state
[ https://issues.apache.org/jira/browse/ARTEMIS-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-2788. - Resolution: Fixed > OpenWire producerId leak in session state > - > > Key: ARTEMIS-2788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.13.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.14.0 > > Time Spent: 20m > Remaining Estimate: 0h > > A session that loops creating and closing producers will demonstrate a leak > in the sessionState of the openwire connection, unchecked it can lead to OOM -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2788) OpenWire producerId leak in session state
[ https://issues.apache.org/jira/browse/ARTEMIS-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124981#comment-17124981 ] ASF subversion and git services commented on ARTEMIS-2788: -- Commit 4eb3fe15f64a37663c36e4a1cd3c7fafc3537e90 in activemq-artemis's branch refs/heads/master from Gary Tully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4eb3fe1 ] Merge pull request #3160 from gtully/ARTEMIS-2788 ARTEMIS-2788 clear openwire producer state on produce close event > OpenWire producerId leak in session state > - > > Key: ARTEMIS-2788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.13.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.14.0 > > Time Spent: 20m > Remaining Estimate: 0h > > A session that loops creating and closing producers will demonstrate a leak > in the sessionState of the openwire connection, unchecked it can lead to OOM -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2788) OpenWire producerId leak in session state
[ https://issues.apache.org/jira/browse/ARTEMIS-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124980#comment-17124980 ] ASF subversion and git services commented on ARTEMIS-2788: -- Commit 4eb3fe15f64a37663c36e4a1cd3c7fafc3537e90 in activemq-artemis's branch refs/heads/master from Gary Tully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4eb3fe1 ] Merge pull request #3160 from gtully/ARTEMIS-2788 ARTEMIS-2788 clear openwire producer state on produce close event > OpenWire producerId leak in session state > - > > Key: ARTEMIS-2788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.13.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.14.0 > > Time Spent: 20m > Remaining Estimate: 0h > > A session that loops creating and closing producers will demonstrate a leak > in the sessionState of the openwire connection, unchecked it can lead to OOM -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2788) OpenWire producerId leak in session state
[ https://issues.apache.org/jira/browse/ARTEMIS-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124979#comment-17124979 ] ASF subversion and git services commented on ARTEMIS-2788: -- Commit 1a5b1fbe8efe69ff19b538490911209ceaf92823 in activemq-artemis's branch refs/heads/master from gtully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=1a5b1fb ] ARTEMIS-2788 clear openwire producer state on produce close event > OpenWire producerId leak in session state > - > > Key: ARTEMIS-2788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.13.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.14.0 > > Time Spent: 10m > Remaining Estimate: 0h > > A session that loops creating and closing producers will demonstrate a leak > in the sessionState of the openwire connection, unchecked it can lead to OOM -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2788) OpenWire producerId leak in session state
[ https://issues.apache.org/jira/browse/ARTEMIS-2788?focusedWorklogId=440780=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-440780 ] ASF GitHub Bot logged work on ARTEMIS-2788: --- Author: ASF GitHub Bot Created on: 03/Jun/20 13:57 Start Date: 03/Jun/20 13:57 Worklog Time Spent: 10m Work Description: gtully merged pull request #3160: URL: https://github.com/apache/activemq-artemis/pull/3160 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 440780) Time Spent: 20m (was: 10m) > OpenWire producerId leak in session state > - > > Key: ARTEMIS-2788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.13.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.14.0 > > Time Spent: 20m > Remaining Estimate: 0h > > A session that loops creating and closing producers will demonstrate a leak > in the sessionState of the openwire connection, unchecked it can lead to OOM -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2788) OpenWire producerId leak in session state
[ https://issues.apache.org/jira/browse/ARTEMIS-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124922#comment-17124922 ] Gary Tully commented on ARTEMIS-2788: - PR https://github.com/apache/activemq-artemis/pull/3160 > OpenWire producerId leak in session state > - > > Key: ARTEMIS-2788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.13.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.14.0 > > Time Spent: 10m > Remaining Estimate: 0h > > A session that loops creating and closing producers will demonstrate a leak > in the sessionState of the openwire connection, unchecked it can lead to OOM -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2788) OpenWire producerId leak in session state
[ https://issues.apache.org/jira/browse/ARTEMIS-2788?focusedWorklogId=440753=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-440753 ] ASF GitHub Bot logged work on ARTEMIS-2788: --- Author: ASF GitHub Bot Created on: 03/Jun/20 12:35 Start Date: 03/Jun/20 12:35 Worklog Time Spent: 10m Work Description: gtully opened a new pull request #3160: URL: https://github.com/apache/activemq-artemis/pull/3160 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 440753) Remaining Estimate: 0h Time Spent: 10m > OpenWire producerId leak in session state > - > > Key: ARTEMIS-2788 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2788 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.13.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.14.0 > > Time Spent: 10m > Remaining Estimate: 0h > > A session that loops creating and closing producers will demonstrate a leak > in the sessionState of the openwire connection, unchecked it can lead to OOM -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2788) OpenWire producerId leak in session state
Gary Tully created ARTEMIS-2788: --- Summary: OpenWire producerId leak in session state Key: ARTEMIS-2788 URL: https://issues.apache.org/jira/browse/ARTEMIS-2788 Project: ActiveMQ Artemis Issue Type: Bug Components: OpenWire Affects Versions: 2.13.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.14.0 A session that loops creating and closing producers will demonstrate a leak in the sessionState of the openwire connection, unchecked it can lead to OOM -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7453) Duplex networkConnector failure with mKahaDB after inactive destinations deleted
[
https://issues.apache.org/jira/browse/AMQ-7453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124828#comment-17124828
]
Anton Roskvist commented on AMQ-7453:
-
I am seeing this issue as well. Some added observations from my side:
Issue can be triggered without automatically removing inactive destinations,
deleting them via JMX has the same effect.
Issue is present even without duplex connections. Setting up brokers with
simplex connections to each other gives the same result.
Issue only seems to happen if it is the last queue in an mKahadb instance that
is removed. So if mKahaDB holds two separate queues or more, one of them seems
to be safe to delete.
Hope that helps.
Br,
Anton
> Duplex networkConnector failure with mKahaDB after inactive destinations
> deleted
>
>
> Key: AMQ-7453
> URL: https://issues.apache.org/jira/browse/AMQ-7453
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, KahaDB
>Affects Versions: 5.15.12
> Environment: Windows 10 Home 64-bit
> Java 1.8.0_45-b14
> ActiveMQ 5.15.12
>Reporter: Anthony Kocherov
>Priority: Major
> Attachments: bad-activemq-restart.debug.log, bad-activemq.debug.log,
> bad-remote-activemq.xml, bad-remote-wrapper.log, good-remote-activemq.xml,
> good-remote-wrapper.log, local-activemq.xml
>
>
> Cannot re-establish duplex network connection on remote broker with following
> error:
> {noformat}
> INFO | jvm 1 | 2020/03/21 14:41:32 | ERROR | Failed to create responder end
> of duplex network bridge Q-bridge@ID:LHC-59471-1584794492297-0:1
> INFO | jvm 1 | 2020/03/21 14:41:32 | java.lang.IllegalStateException:
> PageFile is not loaded
> INFO | jvm 1 | 2020/03/21 14:41:32 | at
> org.apache.activemq.store.kahadb.disk.page.PageFile.assertLoaded(PageFile.java:906)[activemq-kahadb-store-5.15.12.jar:5.15.12]
> ...{noformat}
> Remote broker is configured to [delete inactive
> destinations|https://activemq.apache.org/delete-inactive-destinations.html]
> and uses mKahaDB persistence adapters for different destinations (as
> described here: [Automatic Per Destination Persistence
> Adapter|https://activemq.apache.org/kahadb]).
> Same setup, but single kahaDB persistence adapter on remote broker is not
> causing the issue.
> See attached files for detailed configuration and logs (configuration allows
> to run both brokers on same PC):
> * local broker config: [^local-activemq.xml]
> * remote broker *bad* config and log (delete inactive dest. + mKahaDB +
> perDestination="true"): [^bad-remote-activemq.xml] , [^bad-remote-wrapper.log]
> * remote broker *good* config and log (delete inactive dest. + kahaDB):
> [^good-remote-activemq.xml] , [^good-remote-wrapper.log]
>
> *Use case*
> Simulate network connection loss and then re-establish duplex communication
> after remote broker destinations were purged due to inactivity:
> 1. clean installation of
> [apache-activemq-5.15.12-bin.zip|https://activemq.apache.org/components/classic/download/]
> 2. start remote broker
> 3. start local broker
> 4. destination queue created automatically on remote (active consumer from
> local broker is also shown correctly in web-console)
> 5. stop local broker
> 6. wait for a while until destination is deleted on remote due to inactivity
> 7. start local broker again
> Steps 6.-7. can be repeated multiple times with the same result. However, if
> required queue is created through web-console on remote broker, duplex bridge
> establishes successfully, but as soon as destination is purged, problem
> repeats: [^bad-activemq.debug.log]
> 8. Problem disappears if remote broker is restarted, but comes back whenever
> inactive destinations are purged once again: [^bad-activemq-restart.debug.log]
>
> *Some observations*
> The main difference I see in logs (good vs bad situation), that in bad
> situation following messages appear after inactive destinations deleted:
> {noformat}
> INFO | jvm 1 | 2020/03/22 11:51:20 | INFO | Stopping async queue tasks
> INFO | jvm 1 | 2020/03/22 11:51:20 | INFO | Stopping async topic tasks
> INFO | jvm 1 | 2020/03/22 11:51:20 | INFO | Stopped KahaDB{noformat}
> Since this moment local broker cannot establish duplex connection any more,
> and it doesn't matter which destinations have been purged – with the same
> name (App.Data) or any other. Also it doesn't matter whether local broker
> already had any successful communication with the remote. As soon as these
> messages appear, broker cannot "create responder end of duplex network
> bridge" because of "PageFile is not loaded".
> When I try to do the same with single kahadb instance, these messages do not
> appear and no such problem.
>
> *Links*
> Original discussion here:
>
[jira] [Comment Edited] (AMQ-7491) ActiveMQ illegal occupation vulnerability
[ https://issues.apache.org/jira/browse/AMQ-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124654#comment-17124654 ] wang Jessie edited comment on AMQ-7491 at 6/3/20, 7:26 AM: --- I have uploaded my script on GitHub. Here is the address [https://github.com/wqqqy/MPInspector/tree/master/Adapter/AMQP10/hack-amqp10_SameContainerId] Also you can refer to this link to see the detail of this issue: [https://github.com/wqqqy/Illegal-Occupation-on-ActiveMQ/blob/master/Illegal%20Occupation.md] Hope I can do some help and thank you for your spending time on it. was (Author: wqy): I have uploaded my script on GitHub. Here is the address [https://github.com/wqqqy/MPInspector/tree/master/Adapter/AMQP10/hack-amqp10_SameContainerId] Also you can refer to this link to use it: [https://github.com/wqqqy/Illegal-Occupation-on-ActiveMQ/blob/master/Illegal%20Occupation.md] > ActiveMQ illegal occupation vulnerability > - > > Key: AMQ-7491 > URL: https://issues.apache.org/jira/browse/AMQ-7491 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 5.15.12 > Environment: We build a script used JavaScript to interact with the > broker in ActiveMQ 5.15.12. > The experiment is performed on Windows10 1903 version. >Reporter: wang Jessie >Priority: Blocker > Labels: security > Attachments: 1590234052205.png > > > *Description:* Two client with the same Container-Id are not allowed to > connect to the broker. When we send *two OPEN packet with same the > Container-Id*, the broker will return error and the client will close the TCP > connection. The client with this Container-Id will *never be able to connect > with the broker* unless the broker resets. This vulnerability can be > exploited by the adversary to perform the aforementioned attacks on many > Container-Id to make a huge set of clients unable to connect with the broker. > As the ActiveMQ are widely adopted by the IoT vendors, this can be a > vulnerability affected a wide range. > Following are the details. > We send *two OPEN packets with the same Container-Id 1* and we can learn from > the log A in the attached picture in the broker side that the broker returned > close packets and the client closed this TCP connection with the broker. > Then we build a new client to connect with the broker using the same > Container-Id 1, we can learn from the log B in the attached pictur that the > broker returned errors as the broker believe the client with Container-Id 1 > already connected. > *Suggestion for repair:* May be the state of the broker after received two > OPEN packets could be checked and the connection state of the client could be > updated when the TCP connection is closed. > > :)I hope what I found can do some help and if you want further discussion, > please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. > Thanks for spending your time on my issue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7491) ActiveMQ illegal occupation vulnerability
[ https://issues.apache.org/jira/browse/AMQ-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124654#comment-17124654 ] wang Jessie edited comment on AMQ-7491 at 6/3/20, 7:23 AM: --- I have uploaded my script on GitHub. Here is the address [https://github.com/wqqqy/MPInspector/tree/master/Adapter/AMQP10/hack-amqp10_SameContainerId] Also you can refer to this link to use it: [https://github.com/wqqqy/Illegal-Occupation-on-ActiveMQ/blob/master/Illegal%20Occupation.md] was (Author: wqy): I have upload my script on GitHub. Here is the address [https://github.com/wqqqy/MPInspector/tree/master/Adapter/AMQP10/hack-amqp10_SameContainerId] > ActiveMQ illegal occupation vulnerability > - > > Key: AMQ-7491 > URL: https://issues.apache.org/jira/browse/AMQ-7491 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 5.15.12 > Environment: We build a script used JavaScript to interact with the > broker in ActiveMQ 5.15.12. > The experiment is performed on Windows10 1903 version. >Reporter: wang Jessie >Priority: Blocker > Labels: security > Attachments: 1590234052205.png > > > *Description:* Two client with the same Container-Id are not allowed to > connect to the broker. When we send *two OPEN packet with same the > Container-Id*, the broker will return error and the client will close the TCP > connection. The client with this Container-Id will *never be able to connect > with the broker* unless the broker resets. This vulnerability can be > exploited by the adversary to perform the aforementioned attacks on many > Container-Id to make a huge set of clients unable to connect with the broker. > As the ActiveMQ are widely adopted by the IoT vendors, this can be a > vulnerability affected a wide range. > Following are the details. > We send *two OPEN packets with the same Container-Id 1* and we can learn from > the log A in the attached picture in the broker side that the broker returned > close packets and the client closed this TCP connection with the broker. > Then we build a new client to connect with the broker using the same > Container-Id 1, we can learn from the log B in the attached pictur that the > broker returned errors as the broker believe the client with Container-Id 1 > already connected. > *Suggestion for repair:* May be the state of the broker after received two > OPEN packets could be checked and the connection state of the client could be > updated when the TCP connection is closed. > > :)I hope what I found can do some help and if you want further discussion, > please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. > Thanks for spending your time on my issue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7491) ActiveMQ illegal occupation vulnerability
[ https://issues.apache.org/jira/browse/AMQ-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124654#comment-17124654 ] wang Jessie commented on AMQ-7491: -- I have upload my script on GitHub. Here is the address [https://github.com/wqqqy/MPInspector/tree/master/Adapter/AMQP10/hack-amqp10_SameContainerId] > ActiveMQ illegal occupation vulnerability > - > > Key: AMQ-7491 > URL: https://issues.apache.org/jira/browse/AMQ-7491 > Project: ActiveMQ > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 5.15.12 > Environment: We build a script used JavaScript to interact with the > broker in ActiveMQ 5.15.12. > The experiment is performed on Windows10 1903 version. >Reporter: wang Jessie >Priority: Blocker > Labels: security > Attachments: 1590234052205.png > > > *Description:* Two client with the same Container-Id are not allowed to > connect to the broker. When we send *two OPEN packet with same the > Container-Id*, the broker will return error and the client will close the TCP > connection. The client with this Container-Id will *never be able to connect > with the broker* unless the broker resets. This vulnerability can be > exploited by the adversary to perform the aforementioned attacks on many > Container-Id to make a huge set of clients unable to connect with the broker. > As the ActiveMQ are widely adopted by the IoT vendors, this can be a > vulnerability affected a wide range. > Following are the details. > We send *two OPEN packets with the same Container-Id 1* and we can learn from > the log A in the attached picture in the broker side that the broker returned > close packets and the client closed this TCP connection with the broker. > Then we build a new client to connect with the broker using the same > Container-Id 1, we can learn from the log B in the attached pictur that the > broker returned errors as the broker believe the client with Container-Id 1 > already connected. > *Suggestion for repair:* May be the state of the broker after received two > OPEN packets could be checked and the connection state of the client could be > updated when the TCP connection is closed. > > :)I hope what I found can do some help and if you want further discussion, > please email me by [wangqiny...@zju.edu.cn|mailto:wangqiny...@zju.edu.cn]. > Thanks for spending your time on my issue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
