[Bug 1698758] Re: Encrypted password causes segmentation fault

Andreas Hasenack andreas at canonical.com
Wed Jul 19 19:22:59 UTC 2017


** Description changed:

  [Impact]
  
   * An explanation of the effects of the bug on users and
  
   * justification for backporting the fix to the stable release.
  
   * In addition, it is helpful, but not required, to include an
     explanation of how the upload fixes this bug.
  
  [Test Case]
  
  * install the packages on the Ubuntu release you are testing:
  $ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
  
  * create the database and populate it with the test users from the attached test-users.sql file:
  $ sudo -u postgres -H createdb userdb
  $ sudo -u postgres -H psql userdb -f test-users.sql
  
  * Create the DB user we will use:
  $ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
- CREATE ROLE
  
  * Grant access:
  $ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
- GRANT
  
  * Create the /var/www/html/.htaccess with this content:
  AuthType basic
  AuthName "My Auth"
  Require valid-user
  AuthBasicProvider pgsql
  Auth_PG_authoritative On
  Auth_PG_host 127.0.0.1
  Auth_PG_port 5432
  Auth_PG_user www
  Auth_PG_pwd password
  Auth_PG_database userdb
  Auth_PG_encrypted on
  Auth_PG_pwd_table UserLogin
  Auth_PG_uid_field Username
  Auth_PG_pwd_field ApachePassword
  
- 
- * Setup access in apache by editing /etc/apache2/sites-enabled/000-default.conf and adding these lines somewhere inside the <virtualhost> section:
+ * Setup access in apache by editing /etc/apache2/sites-
+ enabled/000-default.conf and adding these lines somewhere inside the
+ <virtualhost> section:
  
  <Directory /var/www/html>
      AllowOverride AuthConfig
  </Directory>
  
  * Enable the mod-auth-pgsql module:
  $ sudo a2enmod 000_auth_pgsql
  
  * Restart apache:
  $ sudo service apache2 restart
  
  This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
   ubuntu-invalidhash
   ubuntu-md5
   ubuntu-sha256
   ubuntu-sha512
   ubuntu-des
  
  The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
  for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
  Testing ubuntu-invalidhash... FAIL
  Testing ubuntu-md5... OK
  Testing ubuntu-sha256... OK
  Testing ubuntu-sha512... OK
  Testing ubuntu-des... OK
  
  The fixed version must have all tests with the result OK.
  
  [Regression Potential]
  
   * discussion of how regressions are most likely to manifest as a result
  of this change.
  
   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.
  
   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.
  
  [Other Info]
  
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
   * and address these questions in advance

** Description changed:

  [Impact]
  
   * An explanation of the effects of the bug on users and
  
   * justification for backporting the fix to the stable release.
  
   * In addition, it is helpful, but not required, to include an
     explanation of how the upload fixes this bug.
  
  [Test Case]
  
  * install the packages on the Ubuntu release you are testing:
  $ sudo apt install apache2 libapache2-mod-auth-pgsql postgresql
  
  * create the database and populate it with the test users from the attached test-users.sql file:
  $ sudo -u postgres -H createdb userdb
  $ sudo -u postgres -H psql userdb -f test-users.sql
  
  * Create the DB user we will use:
  $ sudo -u postgres -H psql postgres -c "CREATE ROLE www UNENCRYPTED PASSWORD 'password' NOSUPERUSER NOCREATEDB NOCREATEROLE INHERIT LOGIN;"
  
  * Grant access:
  $ sudo -u postgres -H psql userdb -c "GRANT SELECT ON TABLE userlogin TO www;"
  
- * Create the /var/www/html/.htaccess with this content:
+ * Create the /var/www/html/.htaccess file with this content:
  AuthType basic
  AuthName "My Auth"
  Require valid-user
  AuthBasicProvider pgsql
  Auth_PG_authoritative On
  Auth_PG_host 127.0.0.1
  Auth_PG_port 5432
  Auth_PG_user www
  Auth_PG_pwd password
  Auth_PG_database userdb
  Auth_PG_encrypted on
  Auth_PG_pwd_table UserLogin
  Auth_PG_uid_field Username
  Auth_PG_pwd_field ApachePassword
  
  * Setup access in apache by editing /etc/apache2/sites-
  enabled/000-default.conf and adding these lines somewhere inside the
  <virtualhost> section:
  
  <Directory /var/www/html>
      AllowOverride AuthConfig
  </Directory>
  
  * Enable the mod-auth-pgsql module:
  $ sudo a2enmod 000_auth_pgsql
  
  * Restart apache:
  $ sudo service apache2 restart
  
  This is now ready for testing. The database was populated with the following usernames, all with the same password "secret":
   ubuntu-invalidhash
   ubuntu-md5
   ubuntu-sha256
   ubuntu-sha512
   ubuntu-des
  
  The username that will cause a segfault is "ubuntu-invalidhash". To test each login, use a loop like this:
  for u in ubuntu-invalidhash ubuntu-md5 ubuntu-sha256 ubuntu-sha512 ubuntu-des; do echo -n "Testing $u... "; curl -f http://$u:secret@localhost/ -o /dev/null -s && echo OK || echo FAIL; done
  Testing ubuntu-invalidhash... FAIL
  Testing ubuntu-md5... OK
  Testing ubuntu-sha256... OK
  Testing ubuntu-sha512... OK
  Testing ubuntu-des... OK
  
  The fixed version must have all tests with the result OK.
  
  [Regression Potential]
  
   * discussion of how regressions are most likely to manifest as a result
  of this change.
  
   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.
  
   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.
  
  [Other Info]
  
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
   * and address these questions in advance

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libapache2-mod-auth-pgsql in Ubuntu.
https://bugs.launchpad.net/bugs/1698758

Title:
  Encrypted password causes segmentation fault

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-auth-pgsql/+bug/1698758/+subscriptions



More information about the Ubuntu-server-bugs mailing list