[ZBX-4916] Every "Zabbix Administrator" can discover the database password Created: 2012 Apr 25  Updated: 2020 Jul 16  Resolved: 2012 Aug 29

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Documentation (D)
Affects Version/s: 1.8.12, 2.0.0rc3
Fix Version/s: None

Type: Defect (Security) Priority: Critical
Reporter: Volker Fröhlich Assignee: Unassigned
Resolution: Won't fix Votes: 0
Labels: daemon, installation, packaging, password, security, user
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

SUSE, RHEL, FEDORA and probably others



 Description   

Every "Zabbix Administrator" can discover the database password, given there's a Zabbix agent on the server machine. Since agent and server are usually run by the same system user, they can access the same files. Therefore the agent can read the server configuration file. Any suitable item can hence report the password. While it can be avoided, it's probably true for most installations, including SUSE and Fedora/EPEL.

  • Be a Zabbix Admin
  • Add a new host if you don't have permissions for the server host
  • Add an agent item like vfs.file.regexp[/etc/zabbix/zabbix_server.conf,^DBPassword] to that host
  • Receive the password

Please change the documentation to suggest two different users for agent and server.

Sadly, this will cause packagers a lot of headache, because it jeopardizes working installations. Files formerly accessible by agents might no longer be accessible and the other way around.

I think creating a new user for the server causes fewest harm, because it hardly affects monitored machines. It can nevertheless cause issues with at least media scripts and external checks.

SELinux might help to ease the situation, but I think it should not be the primary protection.



 Comments   
Comment by richlv [ 2012 Apr 26 ]

huge thanks for figuring this one out. seems simple, but wasn't brought up till now, as far as i recall.

essentially, our docs should highly suggest running server & agent on the same system with different usernames, and explain why

Comment by Martins Valkovskis [ 2012 Apr 26 ]

Documented at:
http://www.zabbix.com/documentation/2.0/manual/installation/install?&#create_user_account
http://www.zabbix.com/documentation/2.0/manual/concepts/server?&#process_user
http://www.zabbix.com/documentation/1.8/manual/installation/installation_from_source?&#step_1

Should be reviewed.

<richlv> looks good to me, but maybe we should use "database password" instead of "DBPassword" ?

<martins-v> yes, done so now.

<richlv> CLOSED

Comment by Oleksii Zagorskyi [ 2012 Apr 26 ]

Implementation of ZBXNEXT-1085 could help to avoid such security risks.

Comment by Oleksii Zagorskyi [ 2012 Apr 26 ]

And should we expect some changes on server(proxy?) daemon side?
Currently server started from root will switch to a 'zabbix' user account. So this task (use separate account for zabbix_server) should be solved at the init script level?

Comment by richlv [ 2012 Apr 26 ]

i don't see anything we could/should do on the daemon level at this time, but we can consult the devs as well

Comment by Volker Fröhlich [ 2012 May 04 ]

Are there news on this topic?

Shall we change the distribution packages? Can you even start the daemons as a different user, as they are now?

Comment by richlv [ 2012 May 04 ]

you can start daemons as a different user if they are started as a non-root user. so this would probably have to be handled in the initscripts

Comment by Alexei Vladishev [ 2012 Aug 29 ]

Discussed with Rich and decided to close it.

Comment by richlv [ 2012 Aug 29 ]

to clarify, it was added to the docs, which could be considered fixing it

Comment by Volker Fröhlich [ 2012 Nov 14 ]

Zabbix packages in Fedora 18 and zabbix20 in EPEL 6 solve the issue by running proxy and server as zabbixsrv.

zabbixsrv is still member of the group zabbix. The idea behind that was, to create least possible hassle when updating.

Comment by richlv [ 2019 Jan 07 ]

ZBX-15420 asks to implement separation in the upstream packages.

Generated at Thu Mar 28 10:42:29 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.