** 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 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
- To test each login, use a loop like this:
+ To try each test 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; result=$?; echo $result; done
Testing ubuntu-invalidhash... 52
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
- The apache logs will show the segfault when ubuntu-invalidhash is tried:
+ Error 52 means "empty reply from server". That's when apache segfaulted:
[Wed Jul 19 19:28:13.808711 2017] [core:notice] [pid 9499:tid
140330145511296] AH00051: child pid 9677 exit signal Segmentation fault (11),
possible coredump in /etc/apache2
-
- Trying just that one manually:
- $ curl http://ubuntu-invalidhash:secret@localhost -o /dev/null -f
- % Total % Received % Xferd Average Speed Time Time Time
Current
- Dload Upload Total Spent Left Speed
- 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
- curl: (52) Empty reply from server
With the fixed version of libapache2-mod-auth-pgsql, the test loop will
just record a normal authentication problem for the ubuntu-invalidhash
user (since the hash is not supported) instead of an "empty reply from
server":
- $ curl http://ubuntu-invalidhash:secret@localhost -o /dev/null -f
- % Total % Received % Xferd Average Speed Time Time Time
Current
- Dload Upload Total Spent Left Speed
- 0 456 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
- curl: (22) The requested URL returned error: 401
-
- And the test loop will return 22 for that user, and no errors for the rest:
$ 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; result=$?; echo $result; done
Testing ubuntu-invalidhash... 22
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
-
[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]
+ The libapache2-mod-auth-pgsql module will cause a segfault error in apache if
its encrypted support is enabled ("Auth_PG_encrypted on") and a hash format not
supported by crypt(3) is used.
- * An explanation of the effects of the bug on users and
+ Since this is an apache module, users might be tempted to use
+ htpasswd(1) to generate such hashes. The option to generate SHA hashes
+ (-s) in particular will generate a hash incompatible with crypt(3),
+ which will then return NULL and cause the segfault in unpatched versions
+ of this apache module.
- * 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.
+ The fix catches the situation when crypt(3) returns NULL and logs the
+ event as an unsupported hash type being found, and denies the login.
[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 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
-
To try each test 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; result=$?; echo $result; done
Testing ubuntu-invalidhash... 52
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
Error 52 means "empty reply from server". That's when apache segfaulted:
[Wed Jul 19 19:28:13.808711 2017] [core:notice] [pid 9499:tid
140330145511296] AH00051: child pid 9677 exit signal Segmentation fault (11),
possible coredump in /etc/apache2
With the fixed version of libapache2-mod-auth-pgsql, the test loop will
just record a normal authentication problem for the ubuntu-invalidhash
user (since the hash is not supported) instead of an "empty reply from
server":
$ 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; result=$?; echo $result; done
Testing ubuntu-invalidhash... 22
Testing ubuntu-md5... 0
Testing ubuntu-sha256... 0
Testing ubuntu-sha512... 0
Testing ubuntu-des... 0
+ And we get this fact logged:
+ [Wed Jul 19 19:38:56.547337 2017] [auth_pgsql:error] [pid 10035:tid
140550732678912] [client 127.0.0.1:56946] [mod_auth_pgsql.c] - ERROR - PG user
ubuntu-invalidhash: unsupported CRYPT format
+
[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
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
