A security issue fixed upstream in monit has been announced: https://www.openwall.com/lists/oss-security/2018/12/23/2 A link to the commit that fixed it is in the message above. Mageia 6 may also be affected.
Assigning to the registered maintainer.
CC: (none) => marja11Assignee: bugsquad => geiger.david68210
Fixed both Cauldron and mga6!
Thanks David! monit-5.22.0-1.1.mga6 from monit-5.22.0-1.1.mga6.src.rpm
Version: Cauldron => 6CC: (none) => geiger.david68210Assignee: geiger.david68210 => qa-bugs
Mageia 6, x86_64 Installed monit and checked out how it works. It is installed with a resource file /etc/monitrc which is only accessible by root. Copied it to ~/.monitrc, which is monit's first port of call. Check syntax: $ monit -t New Monit id: b948f8eb1ed0ca1a64c4cdea0d3b7cb1 Stored in '/home/lcl/.monit.id' Control file syntax OK There is a description of what triggers the 'use after free' vulnerability in the links from the link in the description (comment 0) which is a bit too involved for me. $ monit Starting Monit 5.22.0 daemon with http interface at [localhost]:2812 $ ls -al .monit.pid -rw-r--r-- 1 lcl lcl 6 Dec 24 18:29 .monit.pid $ cat .monit.pid 12018 $ ls /proc/12018 attr/ exe@ mountinfo personality statm autogroup fd/ mounts projid_map status auxv fdinfo/ mountstats root@ syscall cgroup gid_map net/ sched task/ clear_refs io ns/ schedstat timers cmdline latency numa_maps sessionid timerslack_ns comm limits oom_adj setgroups uid_map coredump_filter loginuid oom_score smaps wchan cpuset map_files/ oom_score_adj smaps_rollup cwd@ maps pagemap stack environ mem patch_state stat Have not quite figured out what a 'service' is. According to the man pages services are started by /etc/init.d by a user admin with password monit. Using the start command always fails on any familiar services like apache: $ sudo systemctl stop httpd $ monit start httpd There is no service named "httpd" This applies under sudo as well. There is a binary file called .monit.state which contains the name of the localhost machine. $ monit stop all $ ls /proc/12018 ls: cannot access '/proc/12018': No such file or directory There are indications that this is working before the update. There are indications that monit is working - the user just needs to understand a little more about it. Installed the latest version from updates testing. $ rpm -qa | grep monit monit-5.22.0-1.1.mga6 $ monit Starting Monit 5.22.0 daemon with http interface at [localhost]:2812 $ cat .monit.pid 30907 $ ps aux | grep monit lcl 30907 0.0 0.0 117148 3812 ? Sl 19:07 0:00 monit Made some edits to .monitrc and checked status: $ monit -t Control file syntax OK $ monit start all There is no service named "wv" The local ruby script wv is running. The script in user's ~/bin uses the shebang to invoke ruby. $ ps aux | grep wv lcl 14609 0.2 0.0 309600 30844 ? Sl Dec21 14:25 ruby /home/lcl/bin/wv 3600 $ monit stop all There is no service named "wv" Edited the .monitrc file again. $ monit start all There is no service named "ruby" Tried adding a check for the availability of workstation canopus by inserting this line in .monitrc: check host canopus with address 192.168.1.xxx $ monit start all There is no service named "canopus" This could be construed as successful because canopus is shut down but in an earlier test using vega, which is running, there was no alert. So this update leaves the impression that the utility works but not in the way a beginner might think. Maybe somebody else knows more about this? .monitrc contains : check program wv with path /home/lcl/bin/wv if status != 0 then alert
CC: (none) => tarazed25
$ monit validate Monit daemon with PID 30907 awakened Monit 5.22.0 uptime: 0m System 'difda' status OK monitoring status Monitored monitoring mode active on reboot start load average [0.06] [0.08] [0.09] cpu 0.2%us 0.5%sy 0.0%wa memory usage 4.6 GB [14.7%] swap usage 0 B [0.0%] uptime 4d 3h 28m boot time Thu, 20 Dec 2018 16:23:20 data collected Mon, 24 Dec 2018 19:51:17 Seems to be running OK anyway.
The last three lines of comment 4 are out of place, they should have been inserted earlier. Distractions = editing errors.
MGA6-32 MATE on IBM Thinkpad R50e No installation issues. Using Len's procedures at CLI: $ monit -t New Monit id: b11ed8f57684575e2c7b10c9ac4daf8b Stored in '/home/tester6/.monit.id' Control file syntax OK $ monit Starting Monit 5.22.0 daemon with http interface at [localhost]:2812 $ ls -al .monit.pid -rw-r--r-- 1 tester6 tester6 6 dec 26 10:38 .monit.pid $ cat .monit.pid 24712 $ ls /proc/24712 attr/ coredump_filter gid_map mem oom_score schedstat statm wchan autogroup cpuset io mountinfo oom_score_adj sessionid status auxv cwd@ latency mounts pagemap setgroups syscall cgroup environ limits mountstats personality smaps task/ clear_refs exe@ loginuid net/ projid_map smaps_rollup timers cmdline fd/ map_files/ ns/ root@ stack timerslack_ns comm fdinfo/ maps oom_adj sched stat uid_map $ monit validate Monit daemon with PID 24712 awakened Monit 5.22.0 uptime: 0m System 'mach6.hviaene.thuis' status OK monitoring status Monitored monitoring mode active on reboot start load average [0.28] [1.18] [1.22] cpu 16.3%us 8.1%sy 3.0%wa memory usage 554.5 MB [55.8%] swap usage 369.2 MB [18.2%] uptime 1h 9m boot time Wed, 26 Dec 2018 09:31:11 data collected Wed, 26 Dec 2018 10:40:39 As indicated by the monit command, pointed the browser to http://localhost:2812/ , used the admin/monit as given in the .monitrc file, and got a sensible display of system status of the laptop, similar to the monit validate command. After disabling the monitoring in the webpage, I get at the CLI: $ monit validate Monit daemon with PID 24712 awakened Monit 5.22.0 uptime: 0m System 'mach6.hviaene.thuis' status Not monitored monitoring status Not monitored monitoring mode active on reboot start data collected Wed, 26 Dec 2018 11:04:06 Seems OK to me.
Whiteboard: (none) => MGA6-32-OKCC: (none) => herman.viaene
Doing the x64 OK for Len. Validating. Advisory made from https://www.openwall.com/lists/oss-security/2018/12/23/2 and comment 2. No CVE (yet).
Whiteboard: MGA6-32-OK => MGA6-32-OK MGA6-64-OKKeywords: (none) => advisory, validated_updateCC: (none) => lewyssmith, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0490.html
Status: NEW => RESOLVEDResolution: (none) => FIXED