CVE-2013-2029

[staatsvr]

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

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?

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!

[tmcdonald]

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.

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.

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.