541776 - [LDAP] Logins with non US-ASCII characters in their password do not work

Status: NEW

(Bugzilla :: User Accounts, defect)

Description

[Werner Moser]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: bugzilla 3.4.4

After upgrading our bugzilla system, which uses LDAP authentication, from 3.0 to 3.4.4 a user could not login in any more.

After some testing we found out, that the a "german umlaut" which he used in his password, was the reason.

I did some testing and found out (by writing the data to a file), that in Bugzilla/Auth/Verify/LDAP.pm the password really is differently encoded comparing version 3.0 an 3.4.4:

the used password ist "testü"
hexcode of bugzlla 3.0: 7465 7374 c3bc 
hexcode of bugzilla 3.4.4: 7465 7374 fc


Reproducible: Always

Steps to Reproduce:
1. login in with password containing german umlaut
2. login fails
3.
Actual Results:  
login denied.

Expected Results:  
login to be successful.

I found that _fix_utf8 is a new function in CGI.pm. For testing I disabled this function and login with german umlauts in the password worked again.

Comment 1

[Vitaly Fedrushkov]

Anybody to confirm, in upgrade context?

Comment 2

[Vitaly Fedrushkov]

Most likely introduced by bug 363153

Comment 3

[Marc Schumann [:Wurblzap]]

I don't have LDAP handy, so I can't confirm, but RADIUS appears to be affected, too. My guess is it's related.

Can't say whether it's upgrade related.

Comment 4

[A. Shimono [:himorin]]

Some questions (to identify what is the actual bug).

1. Did the instance use utf-8 for its data when 3.0? I think we have used non-utf-8 char code at then.
2. Does a new created account on 3.4.4, including on DB or LDAP, show the same problem?
3. What is the actual data in LDAP? Such as dumped with slapcat or something.

AFAIK, bugzilla doesn't have a feature to create accounts to LDAP by itself. So users SHOULD create their accounts (on LDAP) with using utf-8 as its code.

Comment 5

[Werner Moser]

hi,

here some answers to your questions:

1. Yes. version 3.0 used UTF-8.
2. yes. additionally, I have changed my domain password (using windows) several times for testing, it's always the same. besides, I do not think that it is a problem of the migration itself but of the new version 3.4.4.
3. cannot verify that, we are using active directory.

All accounts were / are created first in active directory, then the user can use bugzilla without any further steps necessary (of course, rights need to be set as needed in bugzilla).

Comment 6

[Werner Moser]

since almost a year has passed: has this problem been investigated / solved?

Comment 7

[Marc Schumann [:Wurblzap]]

No, unfortunately afaik there has been neither investigation nor progress on this. Do you think you can help? If I'd do it, I'd look into
Bugzilla/Auth/Verify/LDAP.pm and try converting the password into different other character set encodings using Encode::from_to and see what happens.

Comment 8

[Frédéric Buclin]

Is it still a problem with 4.0? Bugzilla 3.x is now restricted to security fixes only, so we won't fix this problem there as it's doesn't enter this category.

Comment 9

[Marc Schumann [:Wurblzap]]

I for one don't know. I know, though, that it's a problem in 4.0 for RADIUS auth.

Comment 11

[Frédéric Buclin]

From bug 601572 (a dupe of this bug), it seems the problem is the encoding of the password:

comment 0:
"From inspecting LDAP traffic using tcpdump, it appears that for the case of the £ symbol, it is passed to the Active Directory server as hex=A3 (ie using the extended ASCII code). If this character is passed instead as hex=C2A3 (ie UTF-8) then authentication will work."

comment 4:
"Active Directory expects passwords to be utf-16, not utf-8, so we may need active-directory specific handling here."

comment 5:
"Though on MS technet, it states that all responses are in UTF-8, so unsure which it should actually be here."

Comment 12

[Ben]

Related to username/password character encoding is an issue where the credential has a colon in it (username or password) as its incorrectly split and results in failed auth (current in version 4.4.4). Can log new bug around this or leave it as a general encoding problem.

Traceback:

 at Bugzilla/Auth/Verify/LDAP.pm line 165
	Bugzilla::Auth::Verify::LDAP::ldap(...) called at Bugzilla/Auth/Verify/LDAP.pm line 139
	Bugzilla::Auth::Verify::LDAP::_bind_ldap_for_search(...) called at Bugzilla/Auth/Verify/LDAP.pm line 37
	Bugzilla::Auth::Verify::LDAP::check_credentials(...) called at Bugzilla/Auth/Verify/Stack.pm line 53
	Bugzilla::Auth::Verify::Stack::check_credentials(...) called at Bugzilla/Auth.pm line 57
	Bugzilla::Auth::login(...) called at Bugzilla.pm line 326
	Bugzilla::login(...) called at /srv/www/htdocs/BugZilla/index.cgi line 25