Nagios Support Forum

Hello, I have a couple questions regarding
CVE-2013-2029 http://www.securityfocus.com/bid/59596
CVE-2013-4214 http://www.securityfocus.com/bid/61747
https://access.redhat.com/security/cve/CVE-2013-2029
https://access.redhat.com/security/cve/CVE-2013-4214

1. Is CVE-2013-2029 (involving nagios.upgrade_to_v3.sh) something introduced by RedHat and therefore Not Applicable to the open source nagios-4.0.1?

2. Or is CVE-2013-2029 this, or is this something new:
In nagios-4.0.1/daemon-init This would appear to create an "Insecure Temporary File Creation Vulnerability" as referenced in these CVEs, e.g.
ln -s /etc/passwd /tmp/.configtest.$GuessedPID
and then would TMPFILE="${prefix}/var/.configtest.$$" be a good fix?

3. Similarly for CVE-2013-4214, in html/rss-corefeed.php or share/rss-newsfeed.php would this be a good fix:
< define('MAGPIE_CACHE_DIR', '/tmp/magpie_cache');
> define('MAGPIE_CACHE_DIR', '/usr/local/nagios/var/magpie_cache');
Noting that the potential issue is mitigated by the default setting of
define('MAGPIE_CACHE_ON', 0);

Thanks!

staatsvr wrote:1. Is CVE-2013-2029 (involving nagios.upgrade_to_v3.sh) something introduced by RedHat and therefore Not Applicable to the open source nagios-4.0.1?

Looks like we have that in our Core 4.0.1 tarball.

staatsvr wrote:2. Or is CVE-2013-2029 this, or is this something new:
In nagios-4.0.1/daemon-init

Code: Select all

 check_config() {
TMPFILE="/tmp/.configtest.$$"
/sbin/service nagios configtest > "$TMPFILE"

This would appear to create an "Insecure Temporary File Creation Vulnerability" as referenced in these CVEs, e.g.
ln -s /etc/passwd /tmp/.configtest.$GuessedPID
and then would TMPFILE="${prefix}/var/.configtest.$$" be a good fix?

Same issue as #1. Depending on the prefix it could work. Others have suggested using mktemp which is more secure but still theoretically vulnerable if you get lucky guessing the filename.

staatsvr wrote:3. Similarly for CVE-2013-4214, in html/rss-corefeed.php or share/rss-newsfeed.php would this be a good fix:
< define('MAGPIE_CACHE_DIR', '/tmp/magpie_cache');
> define('MAGPIE_CACHE_DIR', '/usr/local/nagios/var/magpie_cache');
Noting that the potential issue is mitigated by the default setting of
define('MAGPIE_CACHE_ON', 0);

Since it is disabled by default it is essentially not an issue. The owner for the /usr/local/nagios/var directory is nagios:nagios, so that magpie cache would be the same, likely with 755 permissions. This would limit any sort of symlink attack by a non-root user.