Fedora has issued an advisory today (February 8): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/A73URKLEFEB5USSGSLKTP7XWE5JUKSB7/ Mageia 7 may also be affected.
Status comment: (none) => Fixed upstream in 4.3.4
Whiteboard: (none) => MGA8TOO, MGA7TOO
pushed in mga7/8 src: zeromq-4.3.4-1.1.mga7 zeromq-4.3.4-1.1.mga8
Assignee: zen25000 => qa-bugsVersion: Cauldron => 8Whiteboard: MGA8TOO, MGA7TOO => MGA7TOOCC: (none) => mageiaStatus comment: Fixed upstream in 4.3.4 => (none)
RPMS list: libzmq5-4.3.4-1.1.mga7 libzmq-devel-4.3.4-1.1.mga7 zeromq-utils-4.3.4-1.1.mga7 libzmq5-4.3.4-1.1.mga8 libzmq-devel-4.3.4-1.1.mga8 zeromq-utils-4.3.4-1.1.mga8
i needed to rebuild for mageia 7: cppzmq-4.3.0-2.1.mga7
(In reply to Nicolas Lécureuil from comment #3) > i needed to rebuild for mageia 7: cppzmq-4.3.0-2.1.mga7 which produces: libcppzmq-devel-4.3.0-2.1.mga7 Barry, shouldn't we fix this to be >= ? Requires: zeromq-devel = %{zmqver} as these rebuilds should not be necessary if we're staying in the same stable branch.
Keywords: (none) => feedbackCC: (none) => zen25000
Advisory: ======================== Updated zeromq packages fix security vulnerabilities: Memory leak in client induced by malicious server without CURVE/ZAP (rhbz#1921972). Stack overflow on server running PUB/XPUB socket (rhbz#1921976). Heap overflow when receiving malformed ZMTP v1 packets (rhbz#1921983). Memory leaks via metadata messages processed by PUB sockets (rhbz#1921989). References: https://lists.zeromq.org/pipermail/zeromq-announce/2021-January/000068.html https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/A73URKLEFEB5USSGSLKTP7XWE5JUKSB7/
first QA Team should start to test, comment #4 needs to be addressed but this is not blocker for this one.
If we don't fix it now, we'll be forced to deal with it again next time. I found something upstream that said that the ABI hadn't changed since 4.1. I see no justification for leaving this packaging error in place.
with this info i agree we can remove this "hack".
(In reply to David Walser from comment #4) > (In reply to Nicolas Lécureuil from comment #3) > > i needed to rebuild for mageia 7: cppzmq-4.3.0-2.1.mga7 > > which produces: > libcppzmq-devel-4.3.0-2.1.mga7 > > Barry, shouldn't we fix this to be >= ? > Requires: zeromq-devel = %{zmqver} > Yes I would think so, but not sure. I was expecting cppzmq to be merged into zeromq by now as there was talk of this happening some time back, but it has not happened. Sorry I missed your question above, as I thought Nicholas was dealing with it, and I have been busy with other real life stuff.
Please try with: pushed in mga7/8 src: - mageia 7: zeromq-4.3.4-1.1.mga7 cppzmq-4.3.0-2.3.mga7 - mageia 8: zeromq-4.3.4-1.1.mga8
Packaging issue in cppzmq still hasn't been fixed.
i thought it was. DOing it now
pushed in mga7/8 src: - mageia 7: zeromq-4.3.4-1.1.mga7 cppzmq-4.3.0-2.4.mga7 - mageia 8: zeromq-4.3.4-1.1.mga8
(In reply to David Walser from comment #2) > RPMS list: > libzmq5-4.3.4-1.1.mga7 > libzmq-devel-4.3.4-1.1.mga7 > zeromq-utils-4.3.4-1.1.mga7 > libzmq5-4.3.4-1.1.mga8 > libzmq-devel-4.3.4-1.1.mga8 > zeromq-utils-4.3.4-1.1.mga8 and: libcppzmq-devel-4.3.0-2.4.mga7 Advisory addendum: Also, the cppzmq package has been rebuilt to fix the broken dependency on zeromq-devel.
Keywords: feedback => (none)
(In reply to Nicolas Lécureuil from comment #12) > i thought it was. DOing it now Make sure this also gets fixed in Cauldron and in Mageia 8 SVN.
(In reply to David Walser from comment #15) > (In reply to Nicolas Lécureuil from comment #12) > > i thought it was. DOing it now > > Make sure this also gets fixed in Cauldron and in Mageia 8 SVN. then, you can add cppzmq-4.7.1-1.1.mga8 on this update request
Yeah, better to fix it now. RPM: libcppzmq-devel-4.7.1-1.1.mga8
MGA 7-64 MATE on Peaq C1011 No installation issues. Lookked at previous updates, not in my league. Leaving for someone else to step in.
CC: (none) => herman.viaene
@Herman: comment 18 OK, shall have a go when time permits.
CC: (none) => tarazed25
mga8, x64 Making a start on this - mga7 later. The only mention of reproducers is with reference to fuzz testing frameworks - not our territory. Bug 25113 points to bug 24186 comment 10 for testing. Started redis system service. # ntopng -i 1 2>&1 27/Mar/2021 16:01:52 [Ntop.cpp:2336] Setting local networks to 127.0.0.0/8,fe80::/10 27/Mar/2021 16:01:52 [Redis.cpp:157] Successfully connected to redis 127.0.0.1:6379@0 27/Mar/2021 16:01:52 [Redis.cpp:157] Successfully connected to redis 127.0.0.1:6379@0 27/Mar/2021 16:01:52 [PcapInterface.cpp:93] Reading packets from 1 [id: 0] 27/Mar/2021 16:01:52 [Ntop.cpp:2441] Registered interface enp3s0 [id: 0] 27/Mar/2021 16:01:52 [main.cpp:312] PID stored in file /var/run/ntopng/ntopng.pid ..... Killed that and updated the packages. redis still running. # ntopng -i 1 2>&1 27/Mar/2021 16:21:21 [Ntop.cpp:2336] Setting local networks to 127.0.0.0/8,fe80::/10 27/Mar/2021 16:21:21 [Redis.cpp:157] Successfully connected to redis 127.0.0.1:6379@0 27/Mar/2021 16:21:21 [Redis.cpp:157] Successfully connected to redis 127.0.0.1:6379@0 27/Mar/2021 16:21:21 [PcapInterface.cpp:93] Reading packets from 1 [id: 0] 27/Mar/2021 16:21:21 [Ntop.cpp:2441] Registered interface enp3s0 [id: 0] ...... 27/Mar/2021 16:21:23 [startup.lua:218] Startup completed: ntopng is now operational 27/Mar/2021 16:21:23 [PeriodicActivities.cpp:172] Each periodic activity script will use 2 threads 27/Mar/2021 16:21:23 [NetworkInterface.cpp:2735] Started packet polling on interface enp3s0 [id: 0]... Logged in to ntopng at localhost:3000 (changed password) and tried various things in the dashboard, ports, hosts, MAC addresses. It all looked functional. $ local_lat usage: local_lat <bind-to> <message-size> <roundtrip-count> # cd /var/lib/ntopng # ls 0/ -1/ category_lists/ plugins0/ # ls 0 alerts/ rrd/ subnetstats/ top_talkers/ # ls 0/top_talkers top_talkers.db Letting this one go.
Whiteboard: MGA7TOO => MGA7TOO MGA8-64-OK
mga7, x64 Started redis. Installed the four packages then updated them from testing. local_lat is available. # ntopng -i 1 2>&1 27/Mar/2021 20:39:52 [Ntop.cpp:1902] Setting local networks to 127.0.0.0/8 27/Mar/2021 20:39:52 [Redis.cpp:127] Successfully connected to redis 127.0.0.1:6379@0 .................. 27/Mar/2021 20:39:52 [PeriodicActivities.cpp:113] Each periodic activity script will use 2 threads 27/Mar/2021 20:39:52 [NetworkInterface.cpp:2577] Started packet polling on interface enp3s0 [id: 0]... Logged in to the ntopng dashboard at localhost:3000. Started various transactions on the LAN. Activity relating to the router and internet access and exchanges with the fileserver and NAS drive appeared to be detected. The wifi printer appeared in the list as well - it must have been polled. Tried the various tabs; piecharts for some of them. Under flows my sister's iPhone showed up. Looks good.
Whiteboard: MGA7TOO MGA8-64-OK => MGA7TOO MGA7-64-OK MGA8-64-OK
Validating. Advisory in Comment 5, with an addendum in Comment 14.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => advisoryCC: (none) => ouaurelien
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0159.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
These now have CVE-2021-2023[4-7]: https://bugzilla.redhat.com/show_bug.cgi?id=1921972 CVE-2021-20234 https://bugzilla.redhat.com/show_bug.cgi?id=1921976 CVE-2021-20236 https://bugzilla.redhat.com/show_bug.cgi?id=1921983 CVE-2021-20235 https://bugzilla.redhat.com/show_bug.cgi?id=1921989 CVE-2021-20237
Summary: zeromq new security issues fixed upstream in 4.3.4 => zeromq new security issues fixed upstream in 4.3.4 (CVE-2021-2023[4-7])