Summary: | <net-analyzer/zabbix-2.0.9_rc1-r2: password leakage (CVE-2013-{5572,5743}) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | alicef, himbeere, mattm |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.redhat.com/show_bug.cgi?id=1013963 | ||
Whiteboard: | B3 [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Agostino Sarubbo
2013-10-01 19:03:19 UTC
Not sure how big of an issue this vulnerability is.....I think upstream has been working on a security issue and this may be related...we'll see if they release a patch or bump for it. Upstream info that I see: This security problem is actual only for zabbix-super-administrator user accounts. When this is considered as a problem: for example I have several zabbix-super-admins but they should not know the LDAP bind pass. Goal: any zabbix-super-admins which doesn't own the password - should not be able to know it (we suppose that they don't have direct shell access to Apache/DB server) Possible solution: For example you typed new "bind password" and pressed the Save button. The new password will be send to Apache and if it's correct it will be stored in the database (as it is currently). Reloaded page will not contain any value in the "bind password" box and source HTML code. I'm not sure, but maybe it would worth to show some grayed default text in the box, like "Password stored into DB, type new password if required." if the password is not empty in the DB. This default text will help a bit after a user has enabled the LDAP auth. If locate a mouse cursor into the box then the default text will disappear (we have already such approach in some places in zabbix frontend). CVE-2013-5572 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-5572): Zabbix 2.0.5 allows remote authenticated users to discover the LDAP bind password by leveraging management-console access and reading the ldap_bind_password value in the HTML source code. NVD says this only affects 2.0.5, not in tree. @maintainers: think we're okay to close? (In reply to Chris Reffett from comment #3) > NVD says this only affects 2.0.5, not in tree. @maintainers: think we're > okay to close? No. https://support.zabbix.com/browse/ZBX-6721 Spoke with upstream...confirmed this is a legitimate issue, upstream has just released 2.0.9rc1 with fix. Details: https://support.zabbix.com/browse/ZBX-7091 Also: http://www.zabbix.com/rn2.0.9rc1.php 2.0.9rc1 in cvs, no keywords temporarily while I test. Matthew, once you are done testing and ready for stabilization please CC arches and ask for stabilization. Whiteboard move to <stable?> Maintainer testing successful for 2.09rc1_r2 bump which is in CVS now with ~amd64 and ~x86 keywords. Suggest 24hr wait to see if there are user reported issues before marking stablereq for x86/amd64 arches. stablereq time...there are minimal differences between old stable and new, no bugs since committing bump(~1 day), tested fine on my system, and bump is supposed to fix security issues. Arches, please test and mark stable: =net-analyzer/zabbix-2.0.9_rc1-r2 Target keywords : "amd64 x86" amd64 stable x86 stable Looks like all arches have stabilized. Removed older stable ebuild impacted by CVE. Security team - up to you to decide on GLSA. Please clean up old lingering security bugs for Zabbix when doing so - about 4+ older bugs. (In reply to Matthew Marlowe from comment #13) > Looks like all arches have stabilized. > Removed older stable ebuild impacted by CVE. > Security team - up to you to decide on GLSA. Please clean up old lingering > security bugs for Zabbix when doing so - about 4+ older bugs. Thanks for the cleaning up the old vulnerable versions. GLSA has already been created and is ready for review. The old security bugs will be closed when the GLSA is sent. *** Bug 488288 has been marked as a duplicate of this bug. *** 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). |