Apache + mod_php + mod_auth_kerb

-------------------------
Vulnerability description
-------------------------

User may impersonate as any other user using Zabbix API when using HTTP authentication.

Please use CVE-2014-1682 to refer to this vulnerability.

-------
Details
-------

After logging into Zabbix using HTTP authentication, users could use user.login API method and pass another user account. This could lead to impersonating of any other user and/or to privilege escalation.

This issue has been reported by Vitaly Shupak.

-----------------
Affected versions
-----------------

All of the Zabbix versions are vulnerable to this problem.

--------------
Fixed versions
--------------

These vulnerabilities have been fixed in the latest releases of Zabbix.

The fix is available in the following Zabbix releases:
2.2.2
2.0.11
1.8.20

Additionally, patches are available for the following Zabbix versions:
2.2.1
1.8.2

RESOLVED for 1.8 in svn://svn.zabbix.com/branches/dev/ZBX-7703 and 2.0 in svn://svn.zabbix.com/branches/dev/ZBX-7703-20.

(1) possible undefined index if $_SERVER['PHP_AUTH_USER'] not exist

jelisejev RESOLVED for 1.8 in r41986 and 2.0 in r41989.

Eduards CLOSED

Tested

Fixed in
1.8.20rc1 r42010,
2.0.11rc1 r42011,
2.2.2rc1 r42012,
2.3.0 r42013.

CLOSED.

Attached a patch for 2.2.1. Note, that the fix contains new translatable strings.

The current patch checks that the user specified in the login call matches the PHP_AUTH_USER variable set by the web server, but this requires that the client know what user is being authenticated, which is not always obvious. For example, when using Kerberos authentication, the client doesn't need to know his principal - the Kerberos libraries take care of that transparently. Furthermore, the web server may rewrite the authenticated user using aname_to_localname mapping, so it's impossible for the client to know for certain which username will be set by the web server in the PHP_AUTH_USER variable.

A better implementation would be to just ignore the user passed to the login API call and always use PHP_AUTH_USER instead. If you want to take that even further, then the login API call should not be required at all when using HTTP authentication.

svn://svn.zabbix.com/branches/dev/ZBX-7703 does not exist. Please try to provide a patch for 1.8.2. Thank you.

(Context: I am one of the maintainers of the official Debian package and need to fix this security issue: https://security-tracker.debian.org/tracker/CVE-2014-1682)

for the record, you should be able to access that branch in the revision before it got deleted, for example :

svn ls svn://svn.zabbix.com/branches/dev/ZBX-7703@42013

Vitaly, I'm not familiar with the details of Kerberos authentication. Could you explain how can a client authenticate without knowing the correct username? Or do you mean that the username used for authentication may not match the one passed in PHP_AUTH_USER?

As for completely skipping the login method: we cannot do it since Zabbix will still generate an internal session for the user and the client needs to know the session ID.

Christoph, I've attached a patch for 1.8.2.

The details of Kerberos aren't primarily the issue. When you’re using HTTP authentication — of any kind — the web server will tell Zabbix the client's identity (in the case of Apache and mod_auth_kerb, in the REMOTE_USER environment variable or PHP_AUTH_USER php variable), as verified via the HTTP authentication exchange. The client should not need to supply it again inside the Zabbix login request — once is enough.

A point which is relevant to Kerberos specifically, though, is that as a practical matter with Kerberos the client may not in fact know the identity it is presenting. That's because the details of Kerberos are abstracted away; the client automatically uses whatever identity is present in its Kerberos credential cache. This is handled by the GSSAPI/Kerberos library on the client: it is responsible for generating an encrypted authentication token that tells the web server the client's identity. The HTTP libraries do not have to deal with any of that.

Vitaly, thanks for the explanation. I've created a separate ZBX for resolving this issue - ZBX-7789.