From the upstream bug at $URL:
Zabbix version 1.8.3 and 1.8.4 has one vulnerability in the popup.php that
enables an attacker to perform a SQL Injection Attack. No authentication required.
IV. VULNERABLE CODE
File popup.php line 1513:
$sql = 'SELECT DISTINCT hostid,host '.
' FROM hosts'.
' WHERE '.DBin_node('hostid', $nodeid).
' AND status IN ('.HOST_STATUS_PROXY_ACTIVE.','.HOST_STATUS_PROXY_PASSIVE.')'.
' ORDER BY host,hostid';
$result = DBselect($sql);
Patrick or Matthew, 1.8.9 is already in the tree. Ok to move forward with stabilization? Thanks.
SQL injection vulnerability in popup.php in Zabbix 1.8.3 and 1.8.4, and
possibly other versions before 1.8.9, allows remote attackers to execute
arbitrary SQL commands via the only_hostid parameter.
I think this might be a duplicate of a prior security vulnerability that was
resolved via making 1.8.7 stable last month. Note that the included link
states that only zabbix version 1.8.3 and 1.8.4 are effected. While there is a
comment there suggesting that users upgrade to 1.8.9, I believe that is just
because it is the newest version and not because it is the first version to
have a fix.
I haven't seen any announcements of security issues with zabbix since the last
update we put into stable, and a quick twitter search also doesn't indicate any
K -- looked at the latest info in the CVE page and it says "possibly other
versions before 1.8.9" impacted...so I've asked the resident zabbix support guy
on the #zabbix irc channel and am waiting for his response -- will update bug
when I hear back.
Any news on this?
(Also, maybe one of the maintainers should clean some of the old versions out of the tree, the current amount of versions seems... excessive.)
Per richlv who provides much of the zabbix community support and who also handles a lot of the commercial training for zabbix:
- The last zabbix version that he is aware of having any security issues is 1.8.5, so our having 1.8.7 stable should be fine (He's relatively up to date, so I would think this is correct)
- He does acknowledge that the CVE entry and other notes can be confusing and suggests that I open up a bug directly with Zabbix to have their engineers fix the wording and to clarify his understanding is correct.
That said, if there are any concerns, 1.8.9-r1 is fine enough with me to stabilize although I'm not sure that it's been 30 days yet.
I plan to close some of the legacy bugs and perhaps cleanup some of the older ebuilds in the tree when the next update comes out in the next month or so. I'm not a big fan of constantly deleting ebuilds just because their not the latest - it gets really annoying for those gentoo servers maintaining servers who perform updates less frequently. But, I agree that we probably should remove anything older than 1.8.7.
Thanks, that sounds good!
I'm certainly not implying that you should clean out every old ebuild; just that there seems a lot of stuff there that probably no one is using anymore. But 1.8.7 has been in the tree for three months now, so it seems like the older stuff should go. And 1.8.8-r0 and 1.8.9-r0 have been the latest version for all of respectively 8 and 4 days, so I really think they could be removed, too. (All in all, we probably agree on most of this.)
Ok, thanks. Just to be safe, since I cannot find anything super-definitive like a commit, I am going to set this as depending on 395005 and we'll get something >=1.8.9 there.
Stabilization completed via 396495; added to existing GLSA request.
Same note as in earlier bug on this ebuild, was glsa ever issued, 1.8.10-r1 has been stable for quite awhile now.
Note that all ebuilds prior to 1.8.10-r1 have been removed from tree, and 1.8.11-r2 is current stable...1.8.13 will be new stable in a few weeks. Security herd - please close this bug if no longer needed.
This issue was resolved and addressed in
GLSA 201311-15 at http://security.gentoo.org/glsa/glsa-201311-15.xml
by GLSA coordinator Sergey Popov (pinkbyte).