Bug 20050 - nagios new security issue CVE-2016-10089
Summary: nagios new security issue CVE-2016-10089
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Guillaume Rousse
QA Contact: Sec team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-30 22:45 CET by David Walser
Modified: 2017-07-07 11:55 CEST (History)
1 user (show)

See Also:
Source RPM: nagios-4.2.4-1.mga6.src.rpm
CVE: CVE-2016-10089
Status comment:


Attachments
Fix for CVE-2016-10089 (1.92 KB, text/plain)
2017-07-02 16:24 CEST, David Walser
Details

Description David Walser 2016-12-30 22:45:12 CET
A CVE has been assigned for an incomplete fix for CVE-2016-8641 in Nagios 4.2.4:
http://openwall.com/lists/oss-security/2016/12/30/6

We do have the protected_hardlinks feature enabled in the kernel, so this isn't a big deal for us, but we should fix it in Cauldron if a fix becomes available.
Comment 1 David Walser 2017-02-01 02:08:42 CET
There's also CVE-2014-5009:
https://lwn.net/Vulnerabilities/713145/
Nicolas Lécureuil 2017-04-25 16:18:12 CEST

CVE: (none) => CVE-2016-10089
CC: (none) => mageia

Comment 2 Guillaume Rousse 2017-05-07 18:08:43 CEST
CVE-2014-5009 does not apply, the vulnerable PHP code is not present in nagios 4.x.

The status of CVE-2016-10089 is quite unclear: the original description says it applies to release 4.2.4 and earlier, but newer releases changelog does not mention having fixed it, nor does any commit. I guess we're still vulnerable.

Status: NEW => ASSIGNED

Comment 3 David Walser 2017-05-07 18:24:24 CEST
Thanks for looking into this.

I don't think the new CVE affects the first hunk with the ramdisk dir, as you can't make a hardlink to a directory.

For the 4 file ones, it looks like it's concerned that if the file doesn't already exist, the echo command (or touch in the last case) will create it, and it will then be owned as root, so they chown it back to nagios.  I would think that it would be better to start with a su nagios -c "touch $file", before echoing data to the file, that way it would ensure it would either be created and owned by nagios, or retain its previous ownership, and the chown wouldn't be necessary.
Comment 4 David Walser 2017-05-07 18:25:09 CEST
I was referring to the fix for previous CVE, just to be clear:
https://github.com/NagiosEnterprises/nagioscore/commit/f2ed227673d3b2da643eb5cad26b2d87674f28c1
Comment 5 Rémi Verschelde 2017-07-01 10:32:58 CEST
There's an upstream bug report for CVE-2016-10089 which was closed without any comment... ¯\_(ツ)_/¯

https://github.com/NagiosEnterprises/nagioscore/issues/353
Comment 6 David Walser 2017-07-01 16:20:23 CEST
(In reply to Rémi Verschelde from comment #5)
> There's an upstream bug report for CVE-2016-10089 which was closed without
> any comment... ¯\_(ツ)_/¯
> 
> https://github.com/NagiosEnterprises/nagioscore/issues/353

That's strange.  It appears it would be a fairly simple patch to write.  I just described how to do it in Comment 3.  It's just a matter of doing it :o)
Comment 7 David Walser 2017-07-02 16:24:22 CEST
Created attachment 9453 [details]
Fix for CVE-2016-10089

OK I wrote a patch to fix this, which you can submit upstream.  See the exploit details in the link in Comment 0.  Even with protected_hardlinks disabled, it should no longer work.
Comment 8 David Walser 2017-07-07 11:55:38 CEST
Fixed in nagios-4.3.1-2.mga6.

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.