Fedora has issued an advisory on May 28: https://lists.fedoraproject.org/pipermail/package-announce/2014-June/134166.html For the first 4 CVEs, it appears that they were fixed in 1.2.3i5 and 1.2.4p1. It's not immediately clear whether 1.2.0p3 is affected, but I'll assume so. For the last CVE, the job directory is not shipped in the package, so apparently it gets created at runtime with permssions that cause this issue. Fedora fixed it by shipping the directory in the package with appropriate permissions. I would think a %post scriplet to fix the directory permissions if it already exists would be appropriate too, but they didn't do that. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
LWN reference for CVE-2014-0243: http://lwn.net/Vulnerabilities/601893/
Committed revision 637577.
CC: (none) => r.wobben
(In reply to roelof Wobben from comment #2) > Committed revision 637577. The name of our package is nagios-check_mk. In Fedora (where you probably got your SPEC from), it's called check_mk. We need to keep ours the same as it was. So, you should restore the realname macro at the top at least, and use it how it was used. The other ones don't need to be defined explicitly (since RPM defines them implicitly). After that, it's really hard to follow all of the changes because you just completely replace the SPEC file. It's better to just keep the SPEC file mostly the same, and just integrate the changes that are needed to update it to the newer version. I'd suggest reverting this revision and starting over.
oke, But still I have to replace the build section because it looks like to me that the old version needs to be changed to work with systemd. The new version works fine with systemd. Roelof
CC: (none) => rwobben
The old version had a patch for systemd support and already had a systemd-check_mk_agent package. I guess the patch may not be needed with the new version. It is quite a long and complicated %install section, it very well may require changes.
(In reply to David Walser from comment #3) > (In reply to roelof Wobben from comment #2) > > Committed revision 637577. > > I'd suggest reverting this revision and starting over. Commit 637577 has been reverted.
Looking into this more carefully, not all of the issues (at least CVE-2014-2330) were fixed in any 1.2.3 release (and the DT advisory hints that CVE-2014-2330 and CVE-2014-2331 weren't fixed upstream at the time it was posted). So, it does appear that an update to at least 1.2.4p1 would be necessary. It does not appear that backporting patches would be a realistic option for this one. The current upstream release is 1.2.4p5. I'll have to leave this up to the package maintainers to update it. Please note the information in Comment 0 about fixing CVE-2014-0243.
CC: r.wobben, rwobben => guillomovitch
well, let's see if this works for cauldron first... not sure on the %post scriptlet for mga4, what did you have in mind? %post agent chmod 0755 %{_localstatedir}/check_mk_agent/job something like this? or g-s ?
(In reply to AL13N from comment #8) > well, let's see if this works for cauldron first... > > not sure on the %post scriptlet for mga4, what did you have in mind? > > %post agent > chmod 0755 %{_localstatedir}/check_mk_agent/job > > > something like this? Not just for mga4, but yes, exactly that.
hmm, it looks like this last CVE was put into 4p5 tarball after all, even though that commit is not in the 4p5 branch... ???
(In reply to AL13N from comment #10) > hmm, it looks like this last CVE was put into 4p5 tarball after all, even > though that commit is not in the 4p5 branch... ??? Not sure what you mean. CVE-2014-0243, if that's the one you're talking about is I guess a upstream issue that can mitigated through packaging, so whether or not it was addressed upstream, we can address it in the package the same way Fedora did (plus the %post that they forgot). If you're talking about something else, then you'll need to clarify.
i'm talking about: - https://bugzilla.redhat.com/show_bug.cgi?id=1101669 - which links to http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=a2ef8d00c53ec9cbd05c4ae2f09b50761130e7ce now, that commit is not in 1.2.4p5 branch so i figured i needed to add it, but then i saw that this code was in the 1.2.4p5 tarball after all... they solved it by having per user subdir in the check_mk_agent/job/ directory instead of having setuid bit set...
(In reply to AL13N from comment #12) > i'm talking about: > - https://bugzilla.redhat.com/show_bug.cgi?id=1101669 > - which links to > http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit; > h=a2ef8d00c53ec9cbd05c4ae2f09b50761130e7ce > > now, that commit is not in 1.2.4p5 branch so i figured i needed to add it, > but then i saw that this code was in the 1.2.4p5 tarball after all... > > they solved it by having per user subdir in the check_mk_agent/job/ > directory instead of having setuid bit set... Ahh, I see. So Fedora's workaround shouldn't be needed anymore. That commit actually *is* in the 1.2.4 branch. It's the last commit before 1.2.4p3 was tagged. So if that change is a big deal, you might want to add a note to the advisory pointing users to the migration notes that upstream mentioned in the commit.
well, we should point to the migration notes anyway, since this is a version upgrade instead of just a minor update. more will have changed than just this...
I commented on the package changelog then i was directed here: Using %post is wrong. Now that the job/ directory is owned by the package, permissions will be enforced by rpm. This is the sane thing to do. So rpm will create its on install/update, make sure the perms as those of the %install's mkdir. So ths %post is useless and just slow down install (spawning a shell that spawn a mkdir for nothing) Just kill the %post and keep the other bits (packaging the jobs directory as this is enough This is also why FC doesn't use a %post.
CC: (none) => thierry.vignaud
Thanks Thierry. It didn't occur to me that rpm would change the directory's permissions if it already existed. This turned out to be irrelevant anyway since upstream completely changed the way it uses that directory, so the %post will be going away for that reason as well.
Fixed in Cauldron in nagios-check_mk-1.2.4p5-2.mga5.
Version: Cauldron => 4Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO
Not sure which versions are affected, but 1.2.4p4 also fixed VE-2014-5338, CVE-2014-5339, CVE-2014-5340: https://bugzilla.redhat.com/show_bug.cgi?id=1132337#c2
(In reply to David Walser from comment #18) > Not sure which versions are affected, but 1.2.4p4 also fixed VE-2014-5338, > CVE-2014-5339, CVE-2014-5340: > https://bugzilla.redhat.com/show_bug.cgi?id=1132337#c2 Fedora has issued an advisory for this on September 19: https://lists.fedoraproject.org/pipermail/package-announce/2014-September/139066.html from http://lwn.net/Vulnerabilities/613807/
what about this on mga4 ? We have check_mk-1.2.3i1 do we update to a new upstream release like in f20 ?
CC: (none) => mageia
(In reply to Nicolas Lécureuil from comment #20) > what about this on mga4 ? We have check_mk-1.2.3i1 Still vulnerable. > do we update to a new upstream release like in f20 ? That appears to be the only solution. IIRC, the migration from 1.2.3 to 1.2.4 is non-trivial.
yes but if we don't have other solution...:) what about a urpmi.README ( or README.urpmi i never recall the good one ).
With only a couple of weeks remaining in Mageia 4's lifetime, we don't have time to fix this and test it. This package has been dropped and no longer exists in Mageia as of Mageia 5. Closing this as OLD.
Status: NEW => RESOLVEDResolution: (none) => OLD