Bug#964318: gosa login broken with PHP 7.4
Control: forwarded -1 https://github.com/gosa-project/gosa-core/pull/33 Hi, On Do 09 Jul 2020 21:54:34 CEST, Wolfgang Schweer wrote: On Mon, Jul 06, 2020 at 12:05:44PM +0200, Wolfgang Schweer wrote: In both encrypt and decrypt cases, the chosen cipher method seems to return 0. This is the case because the chosen method (aes-256-ecb) doesn't use an initialization vector ($iv) at all, causing its length ($ivlen) to be 0, see e.g. https://usr.ed48.com/php/ssl/?xf=7 So the encrypt/decrypt implementation seems to have been sort of wrong before (and only now with PHP 7.4 an error is thrown). Please check and test the attached changes to /usr/share/gosa/include/functions.inc and /usr/sbin/gosa-encrypt-passwords; works for me, but then my skills are low level and this is a quite sensitive issue. Wolfgang patch submitted upstream. https://github.com/gosa-project/gosa-core/pull/33 Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpO_IaXRLe8T.pgp Description: Digitale PGP-Signatur
Bug#964318: gosa login broken with PHP 7.4
Hi Wolfgang, On Do 09 Jul 2020 21:54:34 CEST, Wolfgang Schweer wrote: On Mon, Jul 06, 2020 at 12:05:44PM +0200, Wolfgang Schweer wrote: In both encrypt and decrypt cases, the chosen cipher method seems to return 0. This is the case because the chosen method (aes-256-ecb) doesn't use an initialization vector ($iv) at all, causing its length ($ivlen) to be 0, see e.g. https://usr.ed48.com/php/ssl/?xf=7 So the encrypt/decrypt implementation seems to have been sort of wrong before (and only now with PHP 7.4 an error is thrown). Please check and test the attached changes to /usr/share/gosa/include/functions.inc and /usr/sbin/gosa-encrypt-passwords; works for me, but then my skills are low level and this is a quite sensitive issue. Wolfgang thanks for looking at this. I'll handle communication with upstream and gosa testing + fixing. Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpPPItmnZbV0.pgp Description: Digitale PGP-Signatur
Bug#964318: gosa login broken with PHP 7.4
On Mon, Jul 06, 2020 at 12:05:44PM +0200, Wolfgang Schweer wrote:
> In both encrypt and decrypt cases, the chosen cipher method seems to
> return 0.
This is the case because the chosen method (aes-256-ecb) doesn't use an
initialization vector ($iv) at all, causing its length ($ivlen) to be 0,
see e.g. https://usr.ed48.com/php/ssl/?xf=7
So the encrypt/decrypt implementation seems to have been sort of wrong
before (and only now with PHP 7.4 an error is thrown).
Please check and test the attached changes to
/usr/share/gosa/include/functions.inc and
/usr/sbin/gosa-encrypt-passwords; works for me, but then my skills are
low level and this is a quite sensitive issue.
Wolfgang
diff -u a/functions.inc b/functions.inc
--- a/functions.inc 2020-04-20 07:32:48.0 +0200
+++ b/functions.inc 2020-07-09 21:09:16.311305601 +0200
@@ -3308,11 +3308,10 @@
}
-function cred_encrypt($input, $password, $cipher = "aes-256-ecb") {
+function cred_encrypt($input, $password) {
+ $cipher = "aes-256-ecb";
if (in_array($cipher, openssl_get_cipher_methods())) {
-$ivlen = openssl_cipher_iv_length($cipher);
-$iv = openssl_random_pseudo_bytes($ivlen);
-return bin2hex(openssl_encrypt($input, $cipher, $password, OPENSSL_RAW_DATA, $iv));
+return bin2hex(openssl_encrypt($input, $cipher, $password));
}
return null;
@@ -3320,9 +3319,7 @@
function cred_decrypt($input, $password, $cipher = "aes-256-ecb") {
if (in_array($cipher, openssl_get_cipher_methods())) {
-$ivlen = openssl_cipher_iv_length($cipher);
-$iv = openssl_random_pseudo_bytes($ivlen);
-return rtrim(openssl_decrypt(pack("H*", $input), $cipher, $password, OPENSSL_RAW_DATA, $iv ), "\0\3\4\n");
+return rtrim(openssl_decrypt(pack("H*", $input), $cipher, $password, $options=0, ), "\0\3\4\n");
}
return null;
diff -u a/gosa-encrypt-passwords b/gosa-encrypt-passwords
--- a/gosa-encrypt-passwords 2020-04-20 07:32:00.0 +0200
+++ b/gosa-encrypt-passwords 2020-07-09 21:07:27.143219922 +0200
@@ -1,11 +1,10 @@
#!/usr/bin/php
signature.asc
Description: PGP signature
Bug#964318: gosa login broken with PHP 7.4
On Sun, Jul 05, 2020 at 10:34:43PM +, Holger Levsen wrote:
> this pretty much sounds like a 'serious' bug ( = unsuitable for a stable
> release as per https://www.debian.org/Bugs/Developer#severities and not
> just important ("major impact, without rendering it completely unusable
> to everyone") or less, though I will follow Wolfgang's example and opt
> for the lesser severity. (maybe it still works with new accounts?)
It doesn't. Also, setting up LDAP from scratch fails as well, i.e.
installation of a new Debian Edu main server is broken.
Error message:
info: Creating first user 'jdoe'.
To initialize a brand new LDAP+KDC:
rm /var/lib/ldap/__db* /var/lib/ldap/*.bdb
rm /etc/krb5kdc/stash /etc/krb5.keytab*
LDAP passwords cleared from debconf database.
The provided LDAP password is valid.
PHP Fatal error: Uncaught Error: Length must be greater than 0 in
/usr/sbin/gosa-encrypt-passwords:7
Stack trace:
#0 /usr/sbin/gosa-encrypt-passwords(7): openssl_random_pseudo_bytes()
#1 /usr/sbin/gosa-encrypt-passwords(74): cred_encrypt()
#2 {main}
thrown in /usr/sbin/gosa-encrypt-passwords on line 7
Related code in /usr/sbin/gosa-encrypt-passwords causing the error:
function cred_encrypt($input, $password, $cipher = "aes-256-ecb") {
if (in_array($cipher, openssl_get_cipher_methods())) {
$ivlen = openssl_cipher_iv_length($cipher);
$iv = openssl_random_pseudo_bytes($ivlen);
return bin2hex(openssl_encrypt($input, $cipher, $password,
OPENSSL_RAW_DATA, $iv));
}
return null;
}
Similar GOSa² web interface related code in /usr/share/gosa/functions.inc:
function cred_encrypt($input, $password, $cipher = "aes-256-ecb") {
if (in_array($cipher, openssl_get_cipher_methods())) {
$ivlen = openssl_cipher_iv_length($cipher);
$iv = openssl_random_pseudo_bytes($ivlen);
return bin2hex(openssl_encrypt($input, $cipher, $password,
OPENSSL_RAW_DATA, $iv));
}
return null;
}
function cred_decrypt($input, $password, $cipher = "aes-256-ecb") {
if (in_array($cipher, openssl_get_cipher_methods())) {
$ivlen = openssl_cipher_iv_length($cipher);
$iv = openssl_random_pseudo_bytes(64);
return rtrim(openssl_decrypt(pack("H*", $input), $cipher, $password,
OPENSSL_RAW_DATA, $iv ), "\0\3\4\n");
}
return null;
}
In both encrypt and decrypt cases, the chosen cipher method seems to return 0.
The severity is rather 'grave', I figure.
@Mike: Also, src:fusiondirectory might be affected.
Wolfgang
signature.asc
Description: PGP signature
Bug#964318: gosa login broken with PHP 7.4
control: severity -1 important
On Sun, Jul 05, 2020 at 05:42:01PM +0200, Wolfgang Schweer wrote:
> while working on Debian Edu Bullseye, I noticed that it is no longer
> possible to log into the GOSa² web interface after a main server
> upgrade.
this pretty much sounds like a 'serious' bug ( = unsuitable for a stable
release as per https://www.debian.org/Bugs/Developer#severities and not
just important ("major impact, without rendering it completely unusable
to everyone") or less, though I will follow Wolfgang's example and opt
for the lesser severity. (maybe it still works with new accounts?)
Mike, please raise the severity further / as needed and more importantly,
please upload a fix! ;) & thank you for maintaining GOSa², we need it! :)
--
cheers,
Holger
---
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
signature.asc
Description: PGP signature
Bug#964318: gosa login broken with PHP 7.4
Package: gosa
Version: 2.7.4+reloaded3-11
Severity: normal
Tags: upstream
Hi Mike,
while working on Debian Edu Bullseye, I noticed that it is no longer
possible to log into the GOSa² web interface after a main server
upgrade.
This error message is popping up:
Fatal error: Uncaught Error: Length must be greater than 0 in
/usr/share/gosa/include/functions.inc:3324 Stack trace:
#0 /usr/share/gosa/include/functions.inc(3324):
openssl_random_pseudo_bytes()
#1 /usr/share/gosa/include/class_config.inc(310): cred_decrypt()
#2 /usr/share/gosa/include/class_config.inc(362): config->get_credentials()
#3 /usr/share/gosa/include/class_configRegistry.inc(408):
config->get_ldap_link()
#4 /usr/share/gosa/include/class_config.inc(453): configRegistry->reload()
#5 /usr/share/gosa/include/class_config.inc(441): config->load_servers()
#6 /usr/share/gosa/html/index.php(267): config->set_current()
#7 {main}
thrown in /usr/share/gosa/include/functions.inc on line 3324
This happened after upgrading the main server.
The error is most probably due to PHP 7.4 incompatible gosa code, see:
https://www.php.net/manual/en/migration74.incompatible.php
Wolfgang
signature.asc
Description: PGP signature
