Bug 20050

Summary: nagios new security issue CVE-2016-10089
Product: Mageia Reporter: David Walser <luigiwalser>
Component: SecurityAssignee: Guillaume Rousse <guillomovitch>
Status: RESOLVED FIXED QA Contact: Sec team <security>
Severity: normal    
Priority: Normal CC: mageia
Version: Cauldron   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Source RPM: nagios-4.2.4-1.mga6.src.rpm CVE: CVE-2016-10089
Status comment:
Attachments: Fix for CVE-2016-10089

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