Bug 476925 - Admin Server: Do not allow 8-bit passwords for the admin user
Admin Server: Do not allow 8-bit passwords for the admin user
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: UI - Admin Express (Show other bugs)
1.1.3
All All
low Severity medium
: ---
: ---
Assigned To: Noriko Hosoi
Viktor Ashirov
:
Depends On:
Blocks: 434915 389_1.3.0
  Show dependency treegraph
 
Reported: 2008-12-17 20:08 EST by Rich Megginson
Modified: 2015-12-07 12:03 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 12:03:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
AS: git patch file (master) (3.25 KB, patch)
2011-03-09 14:20 EST, Noriko Hosoi
nhosoi: review?
rmeggins: review+
Details | Diff
389-admin-console: git patch file (master) (2.58 KB, patch)
2011-03-09 14:21 EST, Noriko Hosoi
nhosoi: review?
rmeggins: review+
Details | Diff
AS: git patch file (master) (2.25 KB, patch)
2011-07-27 13:57 EDT, Noriko Hosoi
nhosoi: review?
rmeggins: review+
Details | Diff

  None (edit)
Description Rich Megginson 2008-12-17 20:08:13 EST
The admin server does not utf8 encode passwords passed to ldap.  The DSGW has code to convert user input data to utf8 for passing to ldap.  We should probably steal that and put it into adminutil for use by all cgi apps.
Comment 2 Noriko Hosoi 2011-03-04 13:30:43 EST
Steps to reproduce:
On Admin Console | Configuration | Access panel
Change password to Liberté.
(NOTE: SingleBytePasswordField handles the password input.  The class does not accept multi-byte characters such as CJK)
Exit console and re-login using "Liberté", which works.

Run ldapsearch with the password.
$ ldapsearch -x -h localhost -p 389 -D 'uid=admin,ou=Administrators,ou=Topologymanagement,o=netscaperoot' -w 'Liberté' -b "dc=example,dc=com" "(uid=*)"
ldap_bind: Invalid credentials (49)
The command line should be passing UTF-8 string.
$ echo $LANG
en_US.UTF-8
This failure indicates the Console is not sending the password in UTF-8.
Comment 3 Noriko Hosoi 2011-03-08 14:51:22 EST
Observations related to the 8-bit password issue.

1) setup-ds-admin.pl
It does not allow 8-bit user name:

    Configuration directory server
    administrator ID [admin]: législature
    The input 'législature' is not a valid ID.  Please choose another one.

It allows 8-bit password:

    Configuration directory server
    administrator ID [admin]:
    Password: compétitions
    Password (confirm): compétitions

The input is the native charset:

    $ echo $LANG
    en_US.UTF-8

Comment in Dialog.pm

    # the $ans and defaultAns should be in the native charset, so the dialog
    # may have to convert to/from utf8 as needed.

2) The password works with the CLU and Java Console (with the modification to allow 8-bit password).

    $ ldapsearch ... -D 'uid=admin,ou=Administrators,ou=TopologyManagement,o=netscaperoot' -w "compétitions" -b "o=netscaperoot" "(cn=*)" dn

3) Login window for the Admin Express is provided by a browser.  The character set used for the login window depends upon the browser.

    Firefox, Safari -- it sends as ISO-8859-1 ==> login fails (charset preference: UTF-8)
    Chrome -- it sends as is(?) ==> login succeeds (charset preference: UTF-8 or ISO-8859-1)

Note: The parent page of the login window is configured with "charset=utf-8"

    <head>
    <title>389 Management Console</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    </head>

There is no tool provided to check the character encoding of the login window.

4) The password is received by the apache api ap_get_basic_auth_pw in admserv_check_user_id (mod_admserv.c).
    /* Get the password that the client sent */
    if ((result = ap_get_basic_auth_pw(r, &sent_pw))) {
        ap_log_rerror(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, 0, r,
                      "[%d] auth_ldap authenticate: "
                      "ap_get_basic_auth_pw() returns %d", getpid(), result);
        return result;
    }
Unfortunately, there is no apache api to get the character set of the sent password (http://httpd.apache.org/dev/apidoc/index.html).  I checked request_rec->content_type in admserv_check_user_id, when the auth request comes in (from Console, Admin Express on Firefox as well as Chrome).  The content type was empty for these3 cases.

Since the same function admserv_check_user_id is used to check the password input by the client and there is no character set information attached to it, we have no way to convert the password to the UTF-8 string (when necessary) on the Admin Server.

Also, the login window is controlled by a browser, it seems there is no way to convert it to some obvious character set before sending, either.

I think the safest way is not to allow 8-bit password as we do for the Admin Server.  One issue is setup-ds-admin.pl allows users to type 8-bit password.  That should be rejected as we do for the admin uid.
Comment 4 Noriko Hosoi 2011-03-09 14:20:09 EST
Created attachment 483289 [details]
AS: git patch file (master)

Description: Due to the following reasons, password of the admin
user is not supposed to include 8-bit characters.
1) Admin Console | Configure | Access does not take 8-bit password.
   If such characters are entered, the characters are dropped.
   (e.g., if "députés" is entered, the password will be "dputs".
2) Character encoding of Admin Express's login window depends on
   browsers' implementation.  And the server has no way to get
   the character encoding information.
Despite of it, setup-ds-admin.pl accepts 8-bit admin user password.
This patch changes the behavior and rejects it.
Comment 5 Noriko Hosoi 2011-03-09 14:21:17 EST
Created attachment 483290 [details]
389-admin-console: git patch file (master)

Description: Admin Console | Configure | Access panel had dropped
User name text box some time back.  The help page was not updated
to reflect the change.  Plus, adding a note about the behavior
to handle passwords containing 8-bit characters.
Comment 6 Noriko Hosoi 2011-03-09 14:44:08 EST
Reviewed by Rich (Thank you!!!)

Pushed to master.

Admin Server:
$ git am `pwd`/0001-Bug-476925-Admin-Server-Do-not-allow-8-bit-passwords.patch
$ git push
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 1007 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/admin.git
   9866d75..e855d30  master -> master

389-admin-console:
$ git merge work
Updating 5d31980..e72728e
Fast-forward
 help/en/header.html                                |    2 +-
 .../configure_administration_server_access.html    |    7 ++++++-
 2 files changed, 7 insertions(+), 2 deletions(-)
Comment 7 Amita Sharma 2011-07-26 09:08:09 EDT
(In reply to comment #4)
> Created attachment 483289 [details]
> AS: git patch file (master)
> 
> Description: Due to the following reasons, password of the admin
> user is not supposed to include 8-bit characters.
> 1) Admin Console | Configure | Access does not take 8-bit password.
>    If such characters are entered, the characters are dropped.

It is still behaving same as stated above, Should we put some error message to deny the password which will say that 8-bit passwords are not allowed because It is currently taking the password (députés) changing it "dputs" and saving it.

>    (e.g., if "députés" is entered, the password will be "dputs".
> 2) Character encoding of Admin Express's login window depends on
>    browsers' implementation.  And the server has no way to get
>    the character encoding information.
> Despite of it, setup-ds-admin.pl accepts 8-bit admin user password.
> This patch changes the behavior and rejects it.

I have executed the setup-ds-admin.pl and gave password as députés. It worked fine then this is also working fine :
ldapsearch -x -p 1389 -h localhost -D "cn=Directory Manager" -w députés -b "cn=config"

But It dose not allow to login to the DS console with this password it says invalid credentials.

So should we have an error message while executing setup-ds-admin.pl?

Am I having the correct build :
[root@amsharma ~]# rpm -qa | grep 389
389-ds-base-devel-1.2.8.2-1.el6_1.7.x86_64
389-console-1.1.7-1.el6.noarch
389-ds-console-1.2.6-1.el6.noarch
389-adminutil-devel-1.1.14-1.el6.x86_64
389-ds-base-libs-1.2.8.2-1.el6_1.7.x86_64
389-admin-console-doc-1.1.7-1.el6.noarch
389-admin-console-1.1.7-1.el6.noarch
389-ds-base-debuginfo-1.2.8.2-1.el6_1.3.x86_64
389-adminutil-1.1.14-1.el6.x86_64
389-ds-1.2.1-2.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-admin-1.1.20-1.el6.x86_64
389-ds-base-1.2.8.2-1.el6_1.7.x86_64
Comment 8 Noriko Hosoi 2011-07-26 16:20:48 EDT
(In reply to comment #7)
   ...
> I have executed the setup-ds-admin.pl and gave password as députés. It worked
> fine then this is also working fine :
> ldapsearch -x -p 1389 -h localhost -D "cn=Directory Manager" -w députés -b
> "cn=config"
   ...
When we call "admin user", it's "uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot" (not "cn=Directory Manager").  This bug fix is just for the admin user.

Please verify 2 things:
1. 8-bit characters are not allowed for the administorator ID password:
    Configuration directory server
    administrator ID [admin]:
    Password: compétitions
    <== This should fail.
2. On the admin console: Admin Console | Configure | Access panel, click help button and check this note is in the online help page:
    Note: if entered password contains non-ascii characters, the characters 
    are dropped.  For instance, you cannot enter one non-ascii character 'é' 
    in the password text boxes.
Comment 9 Amita Sharma 2011-07-27 03:03:47 EDT
Please enter the administrator ID for the configuration directory
server.  This is the ID typically used to log in to the console.  You
will also be prompted for the password.

Configuration directory server
administrator ID [admin]: 
Password: compétitions
Password (confirm): compétitions

The admin server was successfully started.
Admin server was successfully created, configured, and started.
Exiting . . .
Log file is '/tmp/setupzI8Fjc.log'


1. It did not fail during the setup and does not give any error message too?
2. but when I tried to login to the ds console with this password, It says Invalid Credentials.
3. help page "Note: if entered password contains non-ascii characters, the characters are dropped. For instance, you cannot enter one non-ascii character 'é' in the password text boxes."
4. One concern I have that, when I am trying to give this 8 bit character password at On the admin console: Admin Console | Configure | Access panel, It does not give any error message there, It should give the error massage like the note we have on help page?

Please guide.
Comment 10 Noriko Hosoi 2011-07-27 13:48:31 EDT
(In reply to comment #9)
> Please enter the administrator ID for the configuration directory
> server.  This is the ID typically used to log in to the console.  You
> will also be prompted for the password.
> 
> Configuration directory server
> administrator ID [admin]: 
> Password: compétitions
> Password (confirm): compétitions
> 
> The admin server was successfully started.
> Admin server was successfully created, configured, and started.
> Exiting . . .
> Log file is '/tmp/setupzI8Fjc.log'
> 
> 
> 1. It did not fail during the setup and does not give any error message too?

It turned out the 8-th bit check in the setup-ds-admin code was not appropriate.  I'm reopening a bug.

> 2. but when I tried to login to the ds console with this password, It says
> Invalid Credentials.

Console automatically drops the 8-th bit characters.  Most likely, you could login with 'comptitions', but it's not a scenario we want to support.

> 3. help page "Note: if entered password contains non-ascii characters, the
> characters are dropped. For instance, you cannot enter one non-ascii character
> 'é' in the password text boxes."
> 4. One concern I have that, when I am trying to give this 8 bit character
> password at On the admin console: Admin Console | Configure | Access panel, It
> does not give any error message there, It should give the error massage like
> the note we have on help page?

The underlying Java class used on the page automatically drops the 8-bit characters.  And the login panel does the same thing, too.  So, if customers type 8-th bit characters in the admin password (e.g., compétitions), the password gets shrunken to a ascii only word (comptitions).  As long as the customers are using the password on the Console, they have no problem to be authenticated.  Once they use it with other tools, e.g., ldap command line tools, they notice the password they have been using does not work there.  The behaviour has not been updated for a long time, so there is not much benefit to fix it now (since we are gradually walking away from Console.)
Comment 11 Noriko Hosoi 2011-07-27 13:57:17 EDT
Created attachment 515573 [details]
AS: git patch file (master)

Description: There was a bug in the code to check whether a
password string contains a character with the 8-th bit on.
This patch fixes it.
Comment 12 Noriko Hosoi 2011-07-27 16:20:25 EDT
Reviewed by Rich (Thank you!!)

Pushed to master.

$ git merge work
Updating 6a0261f..58600d4
Fast-forward
 admserv/newinst/src/ConfigDSDialogs.pm |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

$ git push
Counting objects: 11, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 704 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/admin.git
   6a0261f..58600d4  master -> master

Verify this bug on the version 1.1.21 or newer.
Comment 13 Amita Sharma 2011-09-12 07:38:58 EDT
followed comment#10, hence VERIFIED.
Comment 14 Amita Sharma 2011-09-12 07:41:01 EDT
while giving compétitions :

Configuration directory server
administrator ID [admin]: 
Password: 
The password contains invalid characters.  Please choose another one.

Note You need to log in before you can comment on or make changes to this bug.