You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a fairly large usage of JeroMQ and we noticed that in certain deployments, the JeroMQ puller stops receiving messages.
This issue seems similiar to what others have reported here and here, except that we hit this issue with PULL
One noticeable thing we found was that the deployments where we hit this issue had Security vulnerability scanner like Tenable or nessus deployed.
On deeper inspection, we have found at least one way to replicate this problem. But we believe there might be more.
This is through the exploit given in zeromq/libzmq#3351 CVE-2019-6250 impacts libczmq version < 4.3.3 with a remote code execution vulnerability
JeroMQ is not impacted by the Remote Code execution but when the exploit payload hits an existing Puller port, it crashes the Io thread causing it to stop processing more messages.
Our assumption is the security vulnerability tools are hitting with this payload since CVE-2019-6250 is a well known vulnerability.
Steps to reproduce
Run a simple Puller which binds to port 6667 and listens indefinitely for messages
Once you run the exploit on the same port, you will notice the following stack trace on Puller and you will notice that it no longer processes the messages sent by the Pusher
java.lang.NegativeArraySizeException: -1
at zmq.Msg.<init>(Msg.java:124)
at zmq.msg.MsgAllocatorHeap.allocate(MsgAllocatorHeap.java:10)
at zmq.msg.MsgAllocatorThreshold.allocate(MsgAllocatorThreshold.java:30)
at zmq.io.coder.Decoder.allocate(Decoder.java:102)
at zmq.io.coder.v2.V2Decoder.allocate(V2Decoder.java:30)
at zmq.io.coder.Decoder.sizeReady(Decoder.java:95)
at zmq.io.coder.v2.V2Decoder.eightByteSizeReady(V2Decoder.java:55)
at zmq.io.coder.Decoder$EightByteSizeReady.apply(Decoder.java:44)
at zmq.io.coder.DecoderBase.decode(DecoderBase.java:113)
at zmq.io.StreamEngine.inEvent(StreamEngine.java:425)
at zmq.io.IOObject.inEvent(IOObject.java:85)
at zmq.poll.Poller.run(Poller.java:273)
at java.base/java.lang.Thread.run(Thread.java:834)
Bug screencast
Simpler JeroMQ testcase
I tried to write this up in a testcase but it blocks indefinitely. With the fix, the testcase passes.
The fix could be as simple as this.
This at least fixes this particular testcase.
We may need to add this check at more places.
If folks agree , I can raise a PR
diff --git a/jeromq-core/src/main/java/zmq/io/coder/v2/V2Decoder.java b/jeromq-core/src/main/java/zmq/io/coder/v2/V2Decoder.java
index d508ebb..48bd129 100644
--- a/jeromq-core/src/main/java/zmq/io/coder/v2/V2Decoder.java
+++ b/jeromq-core/src/main/java/zmq/io/coder/v2/V2Decoder.java
@@ -51,6 +51,9 @@ public class V2Decoder extends Decoder
tmpbuf.position(0);
tmpbuf.limit(8);
final long size = Wire.getUInt64(tmpbuf, 0);
+ if ( size < 0 ) {
+ return Step.Result.ERROR;
+ }
Step.Result rc = sizeReady(size);
if (rc != Step.Result.ERROR) {
The text was updated successfully, but these errors were encountered:
Background
We have a fairly large usage of JeroMQ and we noticed that in certain deployments, the JeroMQ puller stops receiving messages.
This issue seems similiar to what others have reported here and here, except that we hit this issue with PULL
One noticeable thing we found was that the deployments where we hit this issue had Security vulnerability scanner like Tenable or nessus deployed.
On deeper inspection, we have found at least one way to replicate this problem. But we believe there might be more.
This is through the exploit given in zeromq/libzmq#3351
CVE-2019-6250 impacts libczmq version < 4.3.3 with a remote code execution vulnerability
JeroMQ is not impacted by the Remote Code execution but when the exploit payload hits an existing Puller port, it crashes the Io thread causing it to stop processing more messages.
Our assumption is the security vulnerability tools are hitting with this payload since CVE-2019-6250 is a well known vulnerability.
Steps to reproduce
Bug screencast
Simpler JeroMQ testcase
I tried to write this up in a testcase but it blocks indefinitely. With the fix, the testcase passes.
Possible fix
The fix could be as simple as this.
This at least fixes this particular testcase.
We may need to add this check at more places.
If folks agree , I can raise a PR
The text was updated successfully, but these errors were encountered: