2022-12-31 15:43:21 |
Christian Froemmel |
bug |
|
|
added bug |
2022-12-31 15:43:21 |
Christian Froemmel |
attachment added |
|
openldap-contrib-sha2.patch https://bugs.launchpad.net/bugs/2000817/+attachment/5638696/+files/openldap-contrib-sha2.patch |
|
2022-12-31 15:55:09 |
Launchpad Janitor |
openldap (Ubuntu): status |
New |
Confirmed |
|
2022-12-31 16:18:55 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
2022-12-31 16:19:03 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
2023-01-04 04:17:46 |
Bryce Harrington |
openldap (Ubuntu): status |
Confirmed |
Triaged |
|
2023-01-04 04:23:02 |
Bryce Harrington |
tags |
patch |
patch server-next |
|
2023-01-04 13:14:15 |
Robie Basak |
tags |
patch server-next |
patch server-todo |
|
2023-01-05 01:20:36 |
Sergio Durigan Junior |
bug |
|
|
added subscriber Ubuntu Server |
2023-01-05 01:20:40 |
Sergio Durigan Junior |
openldap (Ubuntu): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
2023-01-18 16:50:26 |
Andreas Hasenack |
openldap (Ubuntu): assignee |
Sergio Durigan Junior (sergiodj) |
Andreas Hasenack (ahasenack) |
|
2023-02-01 20:59:55 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/openldap/+git/openldap/+merge/436723 |
|
2023-02-02 12:36:49 |
Andreas Hasenack |
openldap (Ubuntu): status |
Triaged |
In Progress |
|
2023-02-06 17:56:57 |
Andreas Hasenack |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030716 |
|
2023-02-06 17:56:57 |
Andreas Hasenack |
bug task added |
|
openldap (Debian) |
|
2023-02-06 17:57:15 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Kinetic |
|
2023-02-06 17:57:15 |
Andreas Hasenack |
bug task added |
|
openldap (Ubuntu Kinetic) |
|
2023-02-06 17:57:15 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Jammy |
|
2023-02-06 17:57:15 |
Andreas Hasenack |
bug task added |
|
openldap (Ubuntu Jammy) |
|
2023-02-06 17:57:15 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Lunar |
|
2023-02-06 17:57:15 |
Andreas Hasenack |
bug task added |
|
openldap (Ubuntu Lunar) |
|
2023-03-01 14:26:06 |
Andreas Hasenack |
openldap (Ubuntu Jammy): status |
New |
In Progress |
|
2023-03-01 14:26:08 |
Andreas Hasenack |
openldap (Ubuntu Kinetic): status |
New |
In Progress |
|
2023-03-01 14:26:11 |
Andreas Hasenack |
openldap (Ubuntu Jammy): assignee |
|
Andreas Hasenack (ahasenack) |
|
2023-03-01 14:26:13 |
Andreas Hasenack |
openldap (Ubuntu Kinetic): assignee |
|
Andreas Hasenack (ahasenack) |
|
2023-03-09 21:17:46 |
Launchpad Janitor |
openldap (Ubuntu Lunar): status |
In Progress |
Fix Released |
|
2023-03-12 17:14:17 |
Andreas Hasenack |
description |
The OpenLDAP-contrib module sha2 (located in contrib/slapd-modules/passwd/sha2/) computes a wrong SHA256/SSHA256-hash on Ubuntu kinetic. This breaks our current password-authentication in ldap.
The problematic computation:
$ slappasswd -s secret -h '{SHA256}' -o module-load=pw-sha2
{SHA256}WIrrpN3OjEVOUf6yrH1j+o+ODuUuNBo979Od4UXnu54=
The (correct) reference-value on the same system (or older ubuntu Versions):
$ echo -n "secret" | openssl dgst -sha256 -binary | openssl enc -base64
K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
We nailed the problem down to a bug in the gcc-optimizer for strict-aliasing. so most probably the gcc-version on kinetic (v12.2.0) is the reason. The workaround is to compile the sha2-Module with the flag "-fno-strict-aliasing". Then the correct value is computed. An example taken from a git-compiled version of OpenLDAP 2.5.13:
$ ./servers/slapd/slappasswd -T passwd -s secret -h '{SHA256}' -o module-load=pw-sha2 -o module-path=contrib/slapd-modules/passwd/sha2/.libs
{SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
Ubuntu:
Description: Ubuntu 22.10
Release: 22.10
OpenLDAP-Package: 2.5.13+dfsg-1ubuntu1 |
[ 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 Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* 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 must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* 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
[Original Description]
The OpenLDAP-contrib module sha2 (located in contrib/slapd-modules/passwd/sha2/) computes a wrong SHA256/SSHA256-hash on Ubuntu kinetic. This breaks our current password-authentication in ldap.
The problematic computation:
$ slappasswd -s secret -h '{SHA256}' -o module-load=pw-sha2
{SHA256}WIrrpN3OjEVOUf6yrH1j+o+ODuUuNBo979Od4UXnu54=
The (correct) reference-value on the same system (or older ubuntu Versions):
$ echo -n "secret" | openssl dgst -sha256 -binary | openssl enc -base64
K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
We nailed the problem down to a bug in the gcc-optimizer for strict-aliasing. so most probably the gcc-version on kinetic (v12.2.0) is the reason. The workaround is to compile the sha2-Module with the flag "-fno-strict-aliasing". Then the correct value is computed. An example taken from a git-compiled version of OpenLDAP 2.5.13:
$ ./servers/slapd/slappasswd -T passwd -s secret -h '{SHA256}' -o module-load=pw-sha2 -o module-path=contrib/slapd-modules/passwd/sha2/.libs
{SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
Ubuntu:
Description: Ubuntu 22.10
Release: 22.10
OpenLDAP-Package: 2.5.13+dfsg-1ubuntu1 |
|
2023-03-12 17:24:15 |
Andreas Hasenack |
description |
[ 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 Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* 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 must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* 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
[Original Description]
The OpenLDAP-contrib module sha2 (located in contrib/slapd-modules/passwd/sha2/) computes a wrong SHA256/SSHA256-hash on Ubuntu kinetic. This breaks our current password-authentication in ldap.
The problematic computation:
$ slappasswd -s secret -h '{SHA256}' -o module-load=pw-sha2
{SHA256}WIrrpN3OjEVOUf6yrH1j+o+ODuUuNBo979Od4UXnu54=
The (correct) reference-value on the same system (or older ubuntu Versions):
$ echo -n "secret" | openssl dgst -sha256 -binary | openssl enc -base64
K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
We nailed the problem down to a bug in the gcc-optimizer for strict-aliasing. so most probably the gcc-version on kinetic (v12.2.0) is the reason. The workaround is to compile the sha2-Module with the flag "-fno-strict-aliasing". Then the correct value is computed. An example taken from a git-compiled version of OpenLDAP 2.5.13:
$ ./servers/slapd/slappasswd -T passwd -s secret -h '{SHA256}' -o module-load=pw-sha2 -o module-path=contrib/slapd-modules/passwd/sha2/.libs
{SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
Ubuntu:
Description: Ubuntu 22.10
Release: 22.10
OpenLDAP-Package: 2.5.13+dfsg-1ubuntu1 |
[ Impact ]
OpenLDAP deployments using the contrib pw-sha2 module are not able to authenticate their users because the SHA2 calculation is done incorrectly.
Even though this is a contrib module, from an upstream PoV, it is shipped in the Ubuntu (and Debian) OpenLDAP packages, and available for use.
Some fix possibilities were discussed in comment #5, and we selected the one with the least impact to OpenLDAP users at large, which is to recompile that module only without the strict-aliasing optimization.
This update makes that change, and also includes a DEP8 change to verify it.
We didn't use a patch for the pw-sha2 Makefile because d/rules overrides the OPT variable in the make command line (https://git.launchpad.net/~ahasenack/ubuntu/+source/openldap/tree/debian/rules?h=lunar-slapd-sha2-2000817#n44)
[ Test Plan ]
# Install slapd and openssl
$ sudo apt install slapd openssl
# Run the following script
#!/bin/bash
reference_hash="{SHA256}$(echo -n secret | openssl dgst -sha256 -binary | openssl enc -base64)"
test_hash=$(slappasswd -s secret -h '{SHA256}' -o module-load=pw-sha2)
echo "Reference hash of \"secret\" (openssl): ${reference_hash}"
echo "slapd's pw-sha2 hash: ${test_hash}"
if [ "${reference_hash}" != "${test_hash}" ]; then
echo "ERROR: hashes differ"
exit 1
else
echo "PASS: hashes are identical"
fi
With the affected openldap package installed, the script should print an error. With the packages from proposed, the hashes should be identical.
[ Where problems could occur ]
The fix is a change of a compiler option strictly when building only the pw-sha2 module, so it's very localized. It could affect the performance of this module (for the worse), but it's already not working correctly.
[ Other Info ]
Not at this time.
[Original Description]
The OpenLDAP-contrib module sha2 (located in contrib/slapd-modules/passwd/sha2/) computes a wrong SHA256/SSHA256-hash on Ubuntu kinetic. This breaks our current password-authentication in ldap.
The problematic computation:
$ slappasswd -s secret -h '{SHA256}' -o module-load=pw-sha2
{SHA256}WIrrpN3OjEVOUf6yrH1j+o+ODuUuNBo979Od4UXnu54=
The (correct) reference-value on the same system (or older ubuntu Versions):
$ echo -n "secret" | openssl dgst -sha256 -binary | openssl enc -base64
K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
We nailed the problem down to a bug in the gcc-optimizer for strict-aliasing. so most probably the gcc-version on kinetic (v12.2.0) is the reason. The workaround is to compile the sha2-Module with the flag "-fno-strict-aliasing". Then the correct value is computed. An example taken from a git-compiled version of OpenLDAP 2.5.13:
$ ./servers/slapd/slappasswd -T passwd -s secret -h '{SHA256}' -o module-load=pw-sha2 -o module-path=contrib/slapd-modules/passwd/sha2/.libs
{SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
Ubuntu:
Description: Ubuntu 22.10
Release: 22.10
OpenLDAP-Package: 2.5.13+dfsg-1ubuntu1 |
|
2023-03-12 17:26:35 |
Andreas Hasenack |
description |
[ Impact ]
OpenLDAP deployments using the contrib pw-sha2 module are not able to authenticate their users because the SHA2 calculation is done incorrectly.
Even though this is a contrib module, from an upstream PoV, it is shipped in the Ubuntu (and Debian) OpenLDAP packages, and available for use.
Some fix possibilities were discussed in comment #5, and we selected the one with the least impact to OpenLDAP users at large, which is to recompile that module only without the strict-aliasing optimization.
This update makes that change, and also includes a DEP8 change to verify it.
We didn't use a patch for the pw-sha2 Makefile because d/rules overrides the OPT variable in the make command line (https://git.launchpad.net/~ahasenack/ubuntu/+source/openldap/tree/debian/rules?h=lunar-slapd-sha2-2000817#n44)
[ Test Plan ]
# Install slapd and openssl
$ sudo apt install slapd openssl
# Run the following script
#!/bin/bash
reference_hash="{SHA256}$(echo -n secret | openssl dgst -sha256 -binary | openssl enc -base64)"
test_hash=$(slappasswd -s secret -h '{SHA256}' -o module-load=pw-sha2)
echo "Reference hash of \"secret\" (openssl): ${reference_hash}"
echo "slapd's pw-sha2 hash: ${test_hash}"
if [ "${reference_hash}" != "${test_hash}" ]; then
echo "ERROR: hashes differ"
exit 1
else
echo "PASS: hashes are identical"
fi
With the affected openldap package installed, the script should print an error. With the packages from proposed, the hashes should be identical.
[ Where problems could occur ]
The fix is a change of a compiler option strictly when building only the pw-sha2 module, so it's very localized. It could affect the performance of this module (for the worse), but it's already not working correctly.
[ Other Info ]
Not at this time.
[Original Description]
The OpenLDAP-contrib module sha2 (located in contrib/slapd-modules/passwd/sha2/) computes a wrong SHA256/SSHA256-hash on Ubuntu kinetic. This breaks our current password-authentication in ldap.
The problematic computation:
$ slappasswd -s secret -h '{SHA256}' -o module-load=pw-sha2
{SHA256}WIrrpN3OjEVOUf6yrH1j+o+ODuUuNBo979Od4UXnu54=
The (correct) reference-value on the same system (or older ubuntu Versions):
$ echo -n "secret" | openssl dgst -sha256 -binary | openssl enc -base64
K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
We nailed the problem down to a bug in the gcc-optimizer for strict-aliasing. so most probably the gcc-version on kinetic (v12.2.0) is the reason. The workaround is to compile the sha2-Module with the flag "-fno-strict-aliasing". Then the correct value is computed. An example taken from a git-compiled version of OpenLDAP 2.5.13:
$ ./servers/slapd/slappasswd -T passwd -s secret -h '{SHA256}' -o module-load=pw-sha2 -o module-path=contrib/slapd-modules/passwd/sha2/.libs
{SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
Ubuntu:
Description: Ubuntu 22.10
Release: 22.10
OpenLDAP-Package: 2.5.13+dfsg-1ubuntu1 |
[ Impact ]
OpenLDAP deployments using the contrib pw-sha2 module are not able to authenticate their users because the SHA2 calculation is done incorrectly.
Even though this is a contrib module, from an upstream PoV, it is shipped in the Ubuntu (and Debian) OpenLDAP packages, and available for use.
Some fix possibilities were discussed in comment #5, and we selected the one with the least impact to OpenLDAP users at large, which is to recompile that module only without the strict-aliasing optimization.
This update makes that change, and also includes a DEP8 change to verify it.
We didn't use a patch for the pw-sha2 Makefile because d/rules overrides the OPT variable in the make command line (https://git.launchpad.net/~ahasenack/ubuntu/+source/openldap/tree/debian/rules?h=lunar-slapd-sha2-2000817#n44)
[ Test Plan ]
# Install slapd and openssl
$ sudo apt install slapd openssl
# Run the following script
#!/bin/bash
reference_hash="{SHA256}$(echo -n secret | openssl dgst -sha256 -binary | openssl enc -base64)"
test_hash=$(slappasswd -s secret -h '{SHA256}' -o module-load=pw-sha2)
echo "Reference hash of \"secret\" (openssl): ${reference_hash}"
echo "slapd's pw-sha2 hash: ${test_hash}"
if [ "${reference_hash}" != "${test_hash}" ]; then
echo "ERROR: hashes differ"
exit 1
else
echo "PASS: hashes are identical"
fi
With the affected openldap package installed, the script should print an error. With the packages from proposed, the hashes should be identical.
[ Where problems could occur ]
The fix is a change of a compiler option strictly when building only the pw-sha2 module, so it's very localized. It could affect the performance of this module (for the worse), but it's already not working correctly.
[ Other Info ]
Not at this time.
[Original Description]
The OpenLDAP-contrib module sha2 (located in contrib/slapd-modules/passwd/sha2/) computes a wrong SHA256/SSHA256-hash on Ubuntu kinetic. This breaks our current password-authentication in ldap.
The problematic computation:
$ slappasswd -s secret -h '{SHA256}' -o module-load=pw-sha2
{SHA256}WIrrpN3OjEVOUf6yrH1j+o+ODuUuNBo979Od4UXnu54=
The (correct) reference-value on the same system (or older ubuntu Versions):
$ echo -n "secret" | openssl dgst -sha256 -binary | openssl enc -base64
K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
We nailed the problem down to a bug in the gcc-optimizer for strict-aliasing. so most probably the gcc-version on kinetic (v12.2.0) is the reason. The workaround is to compile the sha2-Module with the flag "-fno-strict-aliasing". Then the correct value is computed. An example taken from a git-compiled version of OpenLDAP 2.5.13:
$ ./servers/slapd/slappasswd -T passwd -s secret -h '{SHA256}' -o module-load=pw-sha2 -o module-path=contrib/slapd-modules/passwd/sha2/.libs
{SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
Ubuntu:
Description: Ubuntu 22.10
Release: 22.10
OpenLDAP-Package: 2.5.13+dfsg-1ubuntu1 |
|
2023-03-12 17:31:30 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/openldap/+git/openldap/+merge/438725 |
|
2023-03-12 17:33:28 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/openldap/+git/openldap/+merge/438726 |
|
2023-03-17 20:14:43 |
Steve Langasek |
openldap (Ubuntu Kinetic): status |
In Progress |
Fix Committed |
|
2023-03-17 20:14:46 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
2023-03-17 20:14:48 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
2023-03-17 20:14:52 |
Steve Langasek |
tags |
patch server-todo |
patch server-todo verification-needed verification-needed-kinetic |
|
2023-03-23 12:51:53 |
Andreas Hasenack |
tags |
patch server-todo verification-needed verification-needed-kinetic |
patch server-todo verification-done-kinetic verification-needed |
|
2023-03-28 19:29:09 |
Bug Watch Updater |
openldap (Debian): status |
Unknown |
Fix Released |
|
2023-03-31 15:13:47 |
Timo Aaltonen |
openldap (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
2023-03-31 15:13:56 |
Timo Aaltonen |
tags |
patch server-todo verification-done-kinetic verification-needed |
patch server-todo verification-done-kinetic verification-needed verification-needed-jammy |
|
2023-03-31 20:51:50 |
Andreas Hasenack |
tags |
patch server-todo verification-done-kinetic verification-needed verification-needed-jammy |
patch server-todo verification-done-jammy verification-done-kinetic verification-needed |
|
2023-04-11 21:19:31 |
Launchpad Janitor |
openldap (Ubuntu Kinetic): status |
Fix Committed |
Fix Released |
|
2023-04-11 21:19:39 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
2023-04-11 21:20:13 |
Launchpad Janitor |
openldap (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
2023-06-21 18:53:00 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~sergiodj/ubuntu/+source/openldap/+git/openldap/+merge/445156 |
|
2023-06-21 18:53:46 |
Sergio Durigan Junior |
merge proposal unlinked |
https://code.launchpad.net/~sergiodj/ubuntu/+source/openldap/+git/openldap/+merge/445156 |
|
|
2023-07-26 19:59:35 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~sergiodj/ubuntu/+source/openldap/+git/openldap/+merge/447816 |
|
2023-07-26 20:00:04 |
Sergio Durigan Junior |
merge proposal unlinked |
https://code.launchpad.net/~sergiodj/ubuntu/+source/openldap/+git/openldap/+merge/447816 |
|
|
2023-07-27 17:18:48 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~sergiodj/ubuntu/+source/openldap/+git/openldap/+merge/447816 |
|