** 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.
  
  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.
  
  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]
+ The patch seems pretty straight forward and uses a well documented crypt(3) 
return value in the case of errors.
  
-  * discussion of how regressions are most likely to manifest as a result
- of this change.
+ This is a very old module that hasn't been built in a while (see [other
+ info] below. It's possible that just by rebuilding it with the new
+ environment available in each ubuntu release since vivid could introduce
+ unknowns. Hopefully, if that happens, it will be immediately noticed by
+ the people who use it and will test this SRU.
  
-  * 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
+ Upstream doesn't have a bugtracker or public code hosting that I could
+ find, so I forwarded the patch via email. No response so far.
+ 
+ This module hasn't been rebuilt since vivid and seems unmaintained, being at 
version 2.0.3 since the precise days:
+  libapache2-mod-auth-pgsql | 2.0.3-5build2    | precise
+  libapache2-mod-auth-pgsql | 2.0.3-6          | trusty
+  libapache2-mod-auth-pgsql | 2.0.3-6.1        | vivid
+  libapache2-mod-auth-pgsql | 2.0.3-6.1        | xenial
+  libapache2-mod-auth-pgsql | 2.0.3-6.1        | yakkety
+  libapache2-mod-auth-pgsql | 2.0.3-6.1        | zesty  
+  libapache2-mod-auth-pgsql | 2.0.3-6.1ubuntu1 | artful 
+ 
+ - Debian's last changelog entry is from August 2013
+ - Fedora killed it in July 2011
+ - I couldn't find it in SuSE

** 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.
  
  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.
  
  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
+ $ 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 $?; 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
+ $ 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 $?; 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]
  The patch seems pretty straight forward and uses a well documented crypt(3) 
return value in the case of errors.
  
  This is a very old module that hasn't been built in a while (see [other
  info] below. It's possible that just by rebuilding it with the new
  environment available in each ubuntu release since vivid could introduce
  unknowns. Hopefully, if that happens, it will be immediately noticed by
  the people who use it and will test this SRU.
  
- 
  [Other Info]
  
  Upstream doesn't have a bugtracker or public code hosting that I could
  find, so I forwarded the patch via email. No response so far.
  
  This module hasn't been rebuilt since vivid and seems unmaintained, being at 
version 2.0.3 since the precise days:
-  libapache2-mod-auth-pgsql | 2.0.3-5build2    | precise
-  libapache2-mod-auth-pgsql | 2.0.3-6          | trusty
-  libapache2-mod-auth-pgsql | 2.0.3-6.1        | vivid
-  libapache2-mod-auth-pgsql | 2.0.3-6.1        | xenial
-  libapache2-mod-auth-pgsql | 2.0.3-6.1        | yakkety
-  libapache2-mod-auth-pgsql | 2.0.3-6.1        | zesty  
-  libapache2-mod-auth-pgsql | 2.0.3-6.1ubuntu1 | artful 
+  libapache2-mod-auth-pgsql | 2.0.3-5build2    | precise
+  libapache2-mod-auth-pgsql | 2.0.3-6          | trusty
+  libapache2-mod-auth-pgsql | 2.0.3-6.1        | vivid
+  libapache2-mod-auth-pgsql | 2.0.3-6.1        | xenial
+  libapache2-mod-auth-pgsql | 2.0.3-6.1        | yakkety
+  libapache2-mod-auth-pgsql | 2.0.3-6.1        | zesty
+  libapache2-mod-auth-pgsql | 2.0.3-6.1ubuntu1 | artful
  
  - Debian's last changelog entry is from August 2013
  - Fedora killed it in July 2011
  - I couldn't find it in SuSE

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to 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-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to