Overview
Request 839566 accepted
Adding bug numbers to previous submission
- New upstream version 4.3.3:
* Denial-of-Service on CURVE/ZAP-protected servers by
unauthenticated clients. (CVE-2020-15166, bsc#1176116)
If a raw TCP socket is opened and connected to an endpoint that is fully
configured with CURVE/ZAP, legitimate clients will not be able to exchange
any message. Handshakes complete successfully, and messages are delivered to
the library, but the server application never receives them.
For more information see the security advisory:
https://github.com/zeromq/libzmq/security/advisories/GHSA-25wp-cf8g-938m
* Stack overflow on server running PUB/XPUB socket (CURVE disabled).
The PUB/XPUB subscription store (mtrie) is traversed using recursive
function calls. In the remove (unsubscription) case, the recursive calls are
NOT tail calls, so even with optimizations the stack grows linearly with the
length of a subscription topic. Topics are under the control of remote
clients - they can send a subscription to arbitrary length topics. An
attacker can thus cause a server to create an mtrie sufficiently large such
that, when unsubscribing, traversal will cause a stack overflow. (bsc#1176258)
For more information see the security advisory:
https://github.com/zeromq/libzmq/security/advisories/GHSA-qq65-x72m-9wr8
* Memory leak in PUB server induced by malicious client(s) without CURVE/ZAP.
Messages with metadata are never processed by PUB sockets, but the metadata
is kept referenced in the PUB object and never freed. (bsc#1176257)
For more information see the security advisory:
https://github.com/zeromq/libzmq/security/advisories/GHSA-4p5v-h92w-6wxw
* Memory leak in client induced by malicious server(s) without CURVE/ZAP.
When a pipe processes a delimiter and is already not in active state but
still has an unfinished message, the message is leaked. (bsc#1176259)
For more information see the security advisory:
https://github.com/zeromq/libzmq/security/advisories/GHSA-wfr2-29gj-5w87
* Heap overflow when receiving malformed ZMTP v1 packets (CURVE disabled).
By crafting a packet which is not valid ZMTP v2/v3, and which has two
messages larger than 8192 bytes, the decoder can be tricked into changing
the recorded size of the 8192 bytes static buffer, which then gets overflown
by the next message. The content that gets written in the overflown memory
is entirely decided by the sender. (bsc#1176256)
For more information see the security advisory:
https://github.com/zeromq/libzmq/security/advisories/GHSA-fc3w-qxf5-7hp6
For complete list of changes, see
https://github.com/zeromq/libzmq/releases/tag/v4.3.3
breaks python-pyzmq
Waiting for a fix in python-pyzmq
Request History
adamm created request
Adding bug numbers to previous submission
- New upstream version 4.3.3:
* Denial-of-Service on CURVE/ZAP-protected servers by
unauthenticated clients. (CVE-2020-15166, bsc#1176116)
If a raw TCP socket is opened and connected to an endpoint that is fully
configured with CURVE/ZAP, legitimate clients will not be able to exchange
any message. Handshakes complete successfully, and messages are delivered to
the library, but the server application never receives them.
For more information see the security advisory:
https://github.com/zeromq/libzmq/security/advisories/GHSA-25wp-cf8g-938m
* Stack overflow on server running PUB/XPUB socket (CURVE disabled).
The PUB/XPUB subscription store (mtrie) is traversed using recursive
function calls. In the remove (unsubscription) case, the recursive calls are
NOT tail calls, so even with optimizations the stack grows linearly with the
length of a subscription topic. Topics are under the control of remote
clients - they can send a subscription to arbitrary length topics. An
attacker can thus cause a server to create an mtrie sufficiently large such
that, when unsubscribing, traversal will cause a stack overflow. (bsc#1176258)
For more information see the security advisory:
https://github.com/zeromq/libzmq/security/advisories/GHSA-qq65-x72m-9wr8
* Memory leak in PUB server induced by malicious client(s) without CURVE/ZAP.
Messages with metadata are never processed by PUB sockets, but the metadata
is kept referenced in the PUB object and never freed. (bsc#1176257)
For more information see the security advisory:
https://github.com/zeromq/libzmq/security/advisories/GHSA-4p5v-h92w-6wxw
* Memory leak in client induced by malicious server(s) without CURVE/ZAP.
When a pipe processes a delimiter and is already not in active state but
still has an unfinished message, the message is leaked. (bsc#1176259)
For more information see the security advisory:
https://github.com/zeromq/libzmq/security/advisories/GHSA-wfr2-29gj-5w87
* Heap overflow when receiving malformed ZMTP v1 packets (CURVE disabled).
By crafting a packet which is not valid ZMTP v2/v3, and which has two
messages larger than 8192 bytes, the decoder can be tricked into changing
the recorded size of the 8192 bytes static buffer, which then gets overflown
by the next message. The content that gets written in the overflown memory
is entirely decided by the sender. (bsc#1176256)
For more information see the security advisory:
https://github.com/zeromq/libzmq/security/advisories/GHSA-fc3w-qxf5-7hp6
For complete list of changes, see
https://github.com/zeromq/libzmq/releases/tag/v4.3.3
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
dimstar accepted review
dimstar_suse set openSUSE:Factory:Staging:H as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:H"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:H"
licensedigger accepted review
ok
RBrownSUSE added factory-staging as a reviewer
Being evaluated by group "factory-staging"
RBrownSUSE accepted review
Unstaged from project "openSUSE:Factory:Staging:H"
dimstar_suse set openSUSE:Factory:Staging:E as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:E"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:E"
dimstar_suse added factory-staging as a reviewer
Being evaluated by group "factory-staging"
dimstar_suse accepted review
Unstaged from project "openSUSE:Factory:Staging:E"
dimstar_suse set openSUSE:Factory:Staging:M as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:M"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:M"
dimstar_suse added factory-staging as a reviewer
Being evaluated by group "factory-staging"
dimstar_suse accepted review
Unstaged from project "openSUSE:Factory:Staging:M"
dimstar_suse set openSUSE:Factory:Staging:D as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:D"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:D"
dimstar_suse accepted review
Staging Project openSUSE:Factory:Staging:D got accepted.
dimstar_suse approved review
Staging Project openSUSE:Factory:Staging:D got accepted.
dimstar_suse accepted request
Staging Project openSUSE:Factory:Staging:D got accepted.
Waiting for python-pyzmq
breaks the python bindings
https://github.com/zeromq/pyzmq/issues/1427