LDAP-PW im Klartext im Fehlerlog

moe 2016-12-05 08:32:59 UTC #1

GuMo,

bei einem geplanten Update war unser LDAP-Server für eine kurze Zeit
nicht erreichbar. Da der asyncwrapper in dieser Zeit aktiv wurde, kam es
zu Fehlern … die sind ja klar weil der LDAP nicht lief.
Dabei fiel aber auf, dass das Admin-PW des LDAP im Klartext in den LOGs
auftaucht. Das ist natürlich nicht so schön … kann man das nicht
verhindern? Ist das vielleicht in der 16.1 schon anders?

Version: 14.3.007 (noch)

Gruß Moe

Permission denied! (egw_exception_no_permission): Can’t connect/bind to
LDAP server
’ldapserver’ and dn=‘cn=admin,dc=domain,dc=local’! #0 /usr/share/egroupware/phpgwapi/inc/class.accounts_ldap.inc.php(158):
ldap->ldapConnect(‘ldapserver’, ‘cn=admin,dc=dom…’,
‘KLARTEXT-LDAP-PW’) #1 /usr/share/egroupware/phpgwapi/inc/class.accounts.inc.php(206):
accounts_ldap->__construct(Object(accounts)) #2 /usr/share/egroupware/phpgwapi/inc/class.accounts.inc.php(159):
accounts->__construct() #3 /usr/share/egroupware/phpgwapi/inc/class.egw.inc.php(160):
accounts::getInstance() #4 /usr/share/egroupware/phpgwapi/inc/class.egw.inc.php(70):
egw->setup(Array, true) #5 /usr/share/egroupware/phpgwapi/inc/functions.inc.php(124):
egw->__construct(Array) #6 /usr/share/egroupware/phpgwapi/cron/asyncservices.php(71):
include(’/usr/share/egro…’) #7 {main}

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

RalfBecker 2016-12-05 13:43:40 UTC #2

Hi Moe,

GuMo,

bei einem geplanten Update war unser LDAP-Server für eine kurze Zeit
nicht erreichbar. Da der asyncwrapper in dieser Zeit aktiv wurde, kam es
zu Fehlern … die sind ja klar weil der LDAP nicht lief.
Dabei fiel aber auf, dass das Admin-PW des LDAP im Klartext in den LOGs
auftaucht. Das ist natürlich nicht so schön … kann man das nicht
verhindern? Ist das vielleicht in der 16.1 schon anders?

Kommt von unserem Exception Handler, der logged einen Trace der
Funktionsaufrufe die zu dem Fehler geführt haben.
Für die Benutzeroberfläche kann man das abstellen bzw. ist es auch per
Default abgestellt. Für das Apache ErrorLog ist es fest immer eingeschaltet.

Sprich Du könntest es nur in direkt im Handler drin auskommentieren:

https://github.com/EGroupware/egroupware/blob/master/api/src/loader/exception.php#L75

Man könnte die Aufrufe so umschreiben, das das Passwort nicht in einem
Funktionsparameter sondern zB in einer Klassenvariable transportiert wird.

Wie gesagt anzeigen tun wir das per default nicht.

Ralf

Version: 14.3.007 (noch)

Gruß Moe

Permission denied! (egw_exception_no_permission): Can’t connect/bind to
LDAP server
’ldapserver’ and dn=‘cn=admin,dc=domain,dc=local’!
#0 /usr/share/egroupware/phpgwapi/inc/class.accounts_ldap.inc.php(158):
ldap->ldapConnect(‘ldapserver’, ‘cn=admin,dc=dom…’,
‘KLARTEXT-LDAP-PW’)
#1 /usr/share/egroupware/phpgwapi/inc/class.accounts.inc.php(206):
accounts_ldap->__construct(Object(accounts))
#2 /usr/share/egroupware/phpgwapi/inc/class.accounts.inc.php(159):
accounts->__construct()
#3 /usr/share/egroupware/phpgwapi/inc/class.egw.inc.php(160):
accounts::getInstance()
#4 /usr/share/egroupware/phpgwapi/inc/class.egw.inc.php(70):
egw->setup(Array, true)
#5 /usr/share/egroupware/phpgwapi/inc/functions.inc.php(124):
egw->__construct(Array)
#6 /usr/share/egroupware/phpgwapi/cron/asyncservices.php(71):
include(’/usr/share/egro…’)
#7 {main}

–
Ralf Becker
EGroupware GmbH [www.egroupware.org]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 631 31657-0

moe 2016-12-07 07:28:50 UTC #3

Hi Ralf,

Kommt von unserem Exception Handler, der logged einen Trace der
Funktionsaufrufe die zu dem Fehler geführt haben.
Für die Benutzeroberfläche kann man das abstellen bzw. ist es auch per
Default abgestellt. Für das Apache ErrorLog ist es fest immer eingeschaltet.

Sprich Du könntest es nur in direkt im Handler drin auskommentieren:

https://github.com/EGroupware/egroupware/blob/master/api/src/loader/exception.php#L75

Man könnte die Aufrufe so umschreiben, das das Passwort nicht in einem
Funktionsparameter sondern zB in einer Klassenvariable transportiert wird.

Wie gesagt anzeigen tun wir das per default nicht.

Vielen Dank für die Info!
Ich möchte da jetzt nicht unbedingt Änderungen am Quellcode durchführen,
die ich später wieder nachpfelgen müsste.
Es wurde nicht in der Oberfläche angezeigt sondern per Email an den
www-data User verschickt. Da diese Logs auch ein Kollege sieht, der
nichts mit dem LDAP zu tun hat, fiel das als sicherheitsrisiko auf.

Vielleicht siehst du das auch so und änderst es bei Gelegenheit.
Oder soll ich ein Ticket im Tracker aufmachen?

Gruß Moe

Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Holger_F 2016-12-15 08:01:41 UTC #4

Man kann die Fehlermeldung fürs Frontend abstellen? Gut

Wir hatten einen externen LDAP Server und wenn die Verbindung dorthin mal unterbrochen war, war nämlich direkt auf dem Login-Screen der LDAP Aufruf mit allen seinen Parametern in plaintext zu sehen. Zum Glück damals nur intern erreichbar gewesen.

Grüße

Holger

dawuid 2016-12-16 22:45:28 UTC #5

Hallo,
ich habe mit der Version 16.1.005 auch das Problem.
Allerdings erscheint im Log nur die Fehlermeldung, das eigentliche Login funktioniert einwandfrei.
Ursache ist die LDAP-ACL Konfiguration
Ausgabe im Log:

PHP Warning: ldap_search(): Search: No such object in /usr/share/egroupware/api/src/Auth/Ldap.php on line 192, referer: https://xyz.de/egroupware/login.php?cd=1&domain=default
#1 /usr/share/egroupware/api/src/Auth/Ldap.php(192): ldap_search(Resource id #39, ‘ou=members,dc=x…’, ‘(&(uid=xyzuser)(ob…’, Array), referer: https://xyz.de/egroupware/login.php?cd=1&domain=default
#2 /usr/share/egroupware/api/src/Auth.php(114): EGroupware\Api\Auth\Ldap->getLastPwdChange(‘xyzuser’), referer: https://xyz.de/egroupware/login.php?cd=1&domain=default
#3 /usr/share/egroupware/api/src/Session.php(517): EGroupware\Api\Auth::check_password_change(NULL), referer: https://xyz.de/egroupware/login.php?cd=1&domain=default
#4 /usr/share/egroupware/login.php(255): EGroupware\Api\Session->create(‘xyzuser@default’, ‘PASSWORT’, ‘text’, false, true, true), referer: https://xyz.de/egroupware/login.php?cd=1&domain=default
#5 {main}, referer: https://xyz.de/egroupware/login.php?cd=1&domain=default

Instance=default, User=, Request=POST https://xyz.de/egroupware/login.php, User-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36, referer: https://xyz.de/egroupware/login.php?cd=1&domain=default

PHP Warning: ldap_get_entries() expects parameter 2 to be resource, boolean given in /usr/share/egroupware/api/src/Auth/Ldap.php on line 193, referer: https://xyz.de/egroupware/login.php?cd=1&domain=default
#1 /usr/share/egroupware/api/src/Auth/Ldap.php(193): ldap_get_entries(Resource id #39, false), referer: https://xyz.de/egroupware/login.php?cd=1&domain=default
#2 /usr/share/egroupware/api/src/Auth.php(114): EGroupware\Api\Auth\Ldap->getLastPwdChange(‘xyzuser’), referer: https://xyz.de/egroupware/login.php?cd=1&domain=default
#3 /usr/share/egroupware/api/src/Session.php(517): EGroupware\Api\Auth::check_password_change(NULL), referer: https://xyz.de/egroupware/login.php?cd=1&domain=default
#4 /usr/share/egroupware/login.php(255): EGroupware\Api\Session->create(‘xyzuser@default’, ‘PASSWORT’, ‘text’, false, true, true), referer: https://xyz.de/egroupware/login.php?cd=1&domain=default
#5 {main}, referer: https://xyz.de/egroupware/login.php?cd=1&domain=default

Instance=default, User=, Request=POST https://xyz.de/egroupware/login.php, User-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36, referer: https://xyz.de/egroupware/login.php?cd=1&domain=default

Verantwortlich dafür sind nach meiner Erkenntnis die LDAP-ACL

So bekomme ich die Fehlermeldung bei der Anmeldung im apache-log (Login und Adressbuch ist aber ok) nach einem ldapmodify:

…
add: olcAccess
olcAccess: {3}to * by self write by dn=“cn=admin,dc=xyz,dc=de” write by * none

Auf diese Weise wird keine Meldung gelogt:
…
add: olcAccess
olcAccess: {3}to * by self write by dn=“cn=admin,dc=xyz,dc=de” write by * read

Irgendwie wird hier für die Methode check_password_change nicht der hinterlegte LDAP-Admin verwendet, da das Login funktioniert.
Liege ich mit dieser Vermutung richtig?
Viele Grüße, Axel