| 2020-06-19 14:48:28 |
Dariusz Gadomski |
bug |
|
|
added bug |
| 2020-06-19 14:48:41 |
Dariusz Gadomski |
nominated for series |
|
Ubuntu Bionic |
|
| 2020-06-19 14:48:41 |
Dariusz Gadomski |
bug task added |
|
openssl (Ubuntu Bionic) |
|
| 2020-06-19 14:53:02 |
Dariusz Gadomski |
bug |
|
|
added subscriber Dan Streetman |
| 2020-06-19 14:53:13 |
Dariusz Gadomski |
tags |
|
sts |
|
| 2020-06-19 14:59:02 |
Dariusz Gadomski |
openssl (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2020-06-19 14:59:14 |
Dariusz Gadomski |
information type |
Public |
Public Security |
|
| 2020-06-19 15:30:36 |
Kai Kasurinen |
bug |
|
|
added subscriber Kai Kasurinen |
| 2020-06-19 15:30:52 |
Kai Kasurinen |
removed subscriber Kai Kasurinen |
|
|
|
| 2020-06-24 06:55:54 |
Dariusz Gadomski |
description |
In FIPS mode on Bionic MD5 is semi-disabled causing some applications to segfault.
Test case:
sudo apt install ntp
ntpq -p
Segmentation fault (core dumped)
What happens there is ntpq wants to iterate all available digests (list_digest_names in ntpq.c). It uses EVP_MD_do_all_sorted for this task.
EVP_MD_do_all_sorted eventually runs openssl_add_all_digests_int in c_alld.c.
For FIPS mode it adds:
EVP_add_digest(EVP_md5());
What happens later in ntpq is (list_md_fn function inside ntpq.c):
ctx = EVP_MD_CTX_new();
EVP_DigestInit(ctx, EVP_get_digestbyname(name));
EVP_DigestFinal(ctx, digest, &digest_len);
First digest it gets is MD5, but while running EVP_DigestInit for it, it gets to this point:
#ifdef OPENSSL_FIPS
if (FIPS_mode()) {
if (!(type->flags & EVP_MD_FLAG_FIPS)
&& !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW)) {
EVPerr(EVP_F_EVP_DIGESTINIT_EX, EVP_R_DISABLED_FOR_FIPS);
return 0;
}
}
#endif
Due to type->flags for MD5 being 0 there's an error set (EVP_R_DISABLED_FOR_FIPS).
After getting back to ntpq.c:
ctx->engine and ctx->digest are not set (due to the mentioned error), hence
inside EVP_DigestFinal_ex (openssl/crypto/evp/digest.c)
OPENSSL_assert(ctx->digest->md_size <= EVP_MAX_MD_SIZE);
causes a segfault (ctx->digest is NULL).
So either MD5 shouldn't be added in FIPS mode or it should have the EVP_MD_FLAG_FIPS to be properly initialized. |
In FIPS mode on Bionic MD5 is semi-disabled causing some applications to segfault.
Test case:
sudo apt install ntp
ntpq -p
Segmentation fault (core dumped)
What happens there is ntpq wants to iterate all available digests (list_digest_names in ntpq.c). It uses EVP_MD_do_all_sorted for this task.
EVP_MD_do_all_sorted eventually runs openssl_add_all_digests_int in c_alld.c.
For FIPS mode it adds:
EVP_add_digest(EVP_md5());
What happens later in ntpq is (list_md_fn function inside ntpq.c):
ctx = EVP_MD_CTX_new();
EVP_DigestInit(ctx, EVP_get_digestbyname(name));
EVP_DigestFinal(ctx, digest, &digest_len);
First digest it gets is MD5, but while running EVP_DigestInit for it, it gets to this point (openssl/crypto/evp/digest.c EVP_DigestInit_ex):
#ifdef OPENSSL_FIPS
if (FIPS_mode()) {
if (!(type->flags & EVP_MD_FLAG_FIPS)
&& !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW)) {
EVPerr(EVP_F_EVP_DIGESTINIT_EX, EVP_R_DISABLED_FOR_FIPS);
return 0;
}
}
#endif
Due to type->flags for MD5 being 0 there's an error set (EVP_R_DISABLED_FOR_FIPS).
After getting back to ntpq.c:
ctx->engine and ctx->digest are not set (due to the mentioned error), hence
inside EVP_DigestFinal_ex (openssl/crypto/evp/digest.c)
OPENSSL_assert(ctx->digest->md_size <= EVP_MAX_MD_SIZE);
causes a segfault (ctx->digest is NULL).
So either MD5 shouldn't be added in FIPS mode or it should have the EVP_MD_FLAG_FIPS to be properly initialized. |
|
| 2020-07-10 16:19:21 |
Joy Latten |
attachment added |
|
debdiff.bionic https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1884265/+attachment/5391374/+files/debdiff.bionic |
|
| 2020-07-10 18:19:38 |
Joy Latten |
description |
In FIPS mode on Bionic MD5 is semi-disabled causing some applications to segfault.
Test case:
sudo apt install ntp
ntpq -p
Segmentation fault (core dumped)
What happens there is ntpq wants to iterate all available digests (list_digest_names in ntpq.c). It uses EVP_MD_do_all_sorted for this task.
EVP_MD_do_all_sorted eventually runs openssl_add_all_digests_int in c_alld.c.
For FIPS mode it adds:
EVP_add_digest(EVP_md5());
What happens later in ntpq is (list_md_fn function inside ntpq.c):
ctx = EVP_MD_CTX_new();
EVP_DigestInit(ctx, EVP_get_digestbyname(name));
EVP_DigestFinal(ctx, digest, &digest_len);
First digest it gets is MD5, but while running EVP_DigestInit for it, it gets to this point (openssl/crypto/evp/digest.c EVP_DigestInit_ex):
#ifdef OPENSSL_FIPS
if (FIPS_mode()) {
if (!(type->flags & EVP_MD_FLAG_FIPS)
&& !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW)) {
EVPerr(EVP_F_EVP_DIGESTINIT_EX, EVP_R_DISABLED_FOR_FIPS);
return 0;
}
}
#endif
Due to type->flags for MD5 being 0 there's an error set (EVP_R_DISABLED_FOR_FIPS).
After getting back to ntpq.c:
ctx->engine and ctx->digest are not set (due to the mentioned error), hence
inside EVP_DigestFinal_ex (openssl/crypto/evp/digest.c)
OPENSSL_assert(ctx->digest->md_size <= EVP_MAX_MD_SIZE);
causes a segfault (ctx->digest is NULL).
So either MD5 shouldn't be added in FIPS mode or it should have the EVP_MD_FLAG_FIPS to be properly initialized. |
[Impact]
In FIPS mode on Bionic MD5 is semi-disabled causing some applications to segfault.
ntpq uses crypto hashes to authenticate its requests. By default it appears to use an internal md5 implementation. However, when compiled with openssl it creates a lists of acceptable hashes from openssl that can be used.
[Test Steps]
Test case:
sudo apt install ntp
ntpq -p
Segmentation fault (core dumped)
What happens there is ntpq wants to iterate all available digests (list_digest_names in ntpq.c). It uses EVP_MD_do_all_sorted for this task.
EVP_MD_do_all_sorted eventually runs openssl_add_all_digests_int in c_alld.c.
For FIPS mode it adds:
EVP_add_digest(EVP_md5());
What happens later in ntpq is (list_md_fn function inside ntpq.c):
ctx = EVP_MD_CTX_new();
EVP_DigestInit(ctx, EVP_get_digestbyname(name));
EVP_DigestFinal(ctx, digest, &digest_len);
First digest it gets is MD5, but while running EVP_DigestInit for it, it gets to this point (openssl/crypto/evp/digest.c EVP_DigestInit_ex):
#ifdef OPENSSL_FIPS
if (FIPS_mode()) {
if (!(type->flags & EVP_MD_FLAG_FIPS)
&& !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW)) {
EVPerr(EVP_F_EVP_DIGESTINIT_EX, EVP_R_DISABLED_FOR_FIPS);
return 0;
}
}
#endif
Due to type->flags for MD5 being 0 there's an error set (EVP_R_DISABLED_FOR_FIPS).
After getting back to ntpq.c:
ctx->engine and ctx->digest are not set (due to the mentioned error), hence
inside EVP_DigestFinal_ex (openssl/crypto/evp/digest.c)
OPENSSL_assert(ctx->digest->md_size <= EVP_MAX_MD_SIZE);
causes a segfault (ctx->digest is NULL).
So either MD5 shouldn't be added in FIPS mode or it should have the EVP_MD_FLAG_FIPS to be properly initialized.
[Regression Potential]
I believe the resolution to check the return code and if unsuccessful, do not include the hash algorithm in the internal ntpq digest list, should not introduce any regression.
It will simply not add md5 and md5_sha1 to its lists of digests when compiled with openssl. Instead it will add the others like sha1, sha2, and sha3. |
|
| 2020-07-13 20:00:13 |
Joy Latten |
description |
[Impact]
In FIPS mode on Bionic MD5 is semi-disabled causing some applications to segfault.
ntpq uses crypto hashes to authenticate its requests. By default it appears to use an internal md5 implementation. However, when compiled with openssl it creates a lists of acceptable hashes from openssl that can be used.
[Test Steps]
Test case:
sudo apt install ntp
ntpq -p
Segmentation fault (core dumped)
What happens there is ntpq wants to iterate all available digests (list_digest_names in ntpq.c). It uses EVP_MD_do_all_sorted for this task.
EVP_MD_do_all_sorted eventually runs openssl_add_all_digests_int in c_alld.c.
For FIPS mode it adds:
EVP_add_digest(EVP_md5());
What happens later in ntpq is (list_md_fn function inside ntpq.c):
ctx = EVP_MD_CTX_new();
EVP_DigestInit(ctx, EVP_get_digestbyname(name));
EVP_DigestFinal(ctx, digest, &digest_len);
First digest it gets is MD5, but while running EVP_DigestInit for it, it gets to this point (openssl/crypto/evp/digest.c EVP_DigestInit_ex):
#ifdef OPENSSL_FIPS
if (FIPS_mode()) {
if (!(type->flags & EVP_MD_FLAG_FIPS)
&& !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW)) {
EVPerr(EVP_F_EVP_DIGESTINIT_EX, EVP_R_DISABLED_FOR_FIPS);
return 0;
}
}
#endif
Due to type->flags for MD5 being 0 there's an error set (EVP_R_DISABLED_FOR_FIPS).
After getting back to ntpq.c:
ctx->engine and ctx->digest are not set (due to the mentioned error), hence
inside EVP_DigestFinal_ex (openssl/crypto/evp/digest.c)
OPENSSL_assert(ctx->digest->md_size <= EVP_MAX_MD_SIZE);
causes a segfault (ctx->digest is NULL).
So either MD5 shouldn't be added in FIPS mode or it should have the EVP_MD_FLAG_FIPS to be properly initialized.
[Regression Potential]
I believe the resolution to check the return code and if unsuccessful, do not include the hash algorithm in the internal ntpq digest list, should not introduce any regression.
It will simply not add md5 and md5_sha1 to its lists of digests when compiled with openssl. Instead it will add the others like sha1, sha2, and sha3. |
[Impact]
In FIPS mode on Bionic MD5 is semi-disabled causing some applications to segfault.
ntpq uses crypto hashes to authenticate its requests. By default it uses md5. However, when compiled with openssl it creates a lists of acceptable hashes from openssl that can be used.
[Test Steps]
Test case:
sudo apt install ntp
ntpq -p
Segmentation fault (core dumped)
What happens there is ntpq wants to iterate all available digests (list_digest_names in ntpq.c). It uses EVP_MD_do_all_sorted for this task.
EVP_MD_do_all_sorted eventually runs openssl_add_all_digests_int in c_alld.c.
For FIPS mode it adds:
EVP_add_digest(EVP_md5());
What happens later in ntpq is (list_md_fn function inside ntpq.c):
ctx = EVP_MD_CTX_new();
EVP_DigestInit(ctx, EVP_get_digestbyname(name));
EVP_DigestFinal(ctx, digest, &digest_len);
First digest it gets is MD5, but while running EVP_DigestInit for it, it gets to this point (openssl/crypto/evp/digest.c EVP_DigestInit_ex):
#ifdef OPENSSL_FIPS
if (FIPS_mode()) {
if (!(type->flags & EVP_MD_FLAG_FIPS)
&& !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW)) {
EVPerr(EVP_F_EVP_DIGESTINIT_EX, EVP_R_DISABLED_FOR_FIPS);
return 0;
}
}
#endif
Due to type->flags for MD5 being 0 there's an error set (EVP_R_DISABLED_FOR_FIPS).
After getting back to ntpq.c:
ctx->engine and ctx->digest are not set (due to the mentioned error), hence
inside EVP_DigestFinal_ex (openssl/crypto/evp/digest.c)
OPENSSL_assert(ctx->digest->md_size <= EVP_MAX_MD_SIZE);
causes a segfault (ctx->digest is NULL).
So either MD5 shouldn't be added in FIPS mode or it should have the EVP_MD_FLAG_FIPS to be properly initialized.
[Regression Potential]
I don't think this should regress ntpq + openssl from the Ubuntu archive.
Current archive ntpq + openssl behaviour:
openssl includes all message digests and hands ntpq a sorted digest-list.
ntpq doesn't check return from EVP_Digest(Init|Final) and assumes all is well and sticks all digests into its list regardless if it is working or not.
i.e.
ntpq> help keytype
function: set key type to use for authenticated requests, one of:
MD4, MD5, RIPEMD160, SHA1, SHAKE128
If somehow openssl library is corrupted and sends back erroneous results, its possible the authentication will just not ever work.
Newly fixed archive ntpq + oenssl beahviour:
openssl includes all message digests and hands ntpq a sorted digest-list.
ntpq checks each one and includes each working digest. With a non-corrupted openssl, everything works fine and ntpq includes each into its list. Ends up with a list identical to the one above.
If somehow opensll library is corrupted and sends back erroneous results, ntpq will hopefully catch it by checking return code and include only those algos that appear to be working. Its possible authentication will work for ntpq.
The difference will be seen in ntpq + fips-openssl. ntpq will check return, and for fips-not-approved algos, return will indicate an error. So these algos will be skipped and ntpq will not include into its digest list. Resulting in a much shorter list of only fips-approved algos.
i.e.
ntpq> help keytype
function: set key type to use for authenticated requests, one of:
SHA1, SHAKE128
Since md5 is ntpq's default auth algo, this will need to be changed to one of the above algos in the config files.
But I think it is somewhat understood that MD5 is bad in a FIPS environment. |
|
| 2020-07-13 20:17:21 |
Joy Latten |
attachment added |
|
Results of running make check in ../tests directory https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1884265/+attachment/5392383/+files/ntp-test-results |
|
| 2020-07-13 20:48:52 |
Joy Latten |
bug |
|
|
added subscriber Joy Latten |
| 2020-07-13 20:49:37 |
Joy Latten |
openssl (Ubuntu): assignee |
|
Joy Latten (j-latten) |
|
| 2020-07-14 20:01:53 |
Steve Beattie |
openssl (Ubuntu Bionic): status |
New |
Confirmed |
|
| 2020-07-14 20:01:58 |
Steve Beattie |
openssl (Ubuntu): status |
New |
In Progress |
|
| 2020-07-14 20:10:18 |
Joy Latten |
summary |
[fips] Not fully initialized digest segfaulting some client applications |
[fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl library. |
|
| 2020-07-14 20:16:25 |
Joy Latten |
description |
[Impact]
In FIPS mode on Bionic MD5 is semi-disabled causing some applications to segfault.
ntpq uses crypto hashes to authenticate its requests. By default it uses md5. However, when compiled with openssl it creates a lists of acceptable hashes from openssl that can be used.
[Test Steps]
Test case:
sudo apt install ntp
ntpq -p
Segmentation fault (core dumped)
What happens there is ntpq wants to iterate all available digests (list_digest_names in ntpq.c). It uses EVP_MD_do_all_sorted for this task.
EVP_MD_do_all_sorted eventually runs openssl_add_all_digests_int in c_alld.c.
For FIPS mode it adds:
EVP_add_digest(EVP_md5());
What happens later in ntpq is (list_md_fn function inside ntpq.c):
ctx = EVP_MD_CTX_new();
EVP_DigestInit(ctx, EVP_get_digestbyname(name));
EVP_DigestFinal(ctx, digest, &digest_len);
First digest it gets is MD5, but while running EVP_DigestInit for it, it gets to this point (openssl/crypto/evp/digest.c EVP_DigestInit_ex):
#ifdef OPENSSL_FIPS
if (FIPS_mode()) {
if (!(type->flags & EVP_MD_FLAG_FIPS)
&& !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW)) {
EVPerr(EVP_F_EVP_DIGESTINIT_EX, EVP_R_DISABLED_FOR_FIPS);
return 0;
}
}
#endif
Due to type->flags for MD5 being 0 there's an error set (EVP_R_DISABLED_FOR_FIPS).
After getting back to ntpq.c:
ctx->engine and ctx->digest are not set (due to the mentioned error), hence
inside EVP_DigestFinal_ex (openssl/crypto/evp/digest.c)
OPENSSL_assert(ctx->digest->md_size <= EVP_MAX_MD_SIZE);
causes a segfault (ctx->digest is NULL).
So either MD5 shouldn't be added in FIPS mode or it should have the EVP_MD_FLAG_FIPS to be properly initialized.
[Regression Potential]
I don't think this should regress ntpq + openssl from the Ubuntu archive.
Current archive ntpq + openssl behaviour:
openssl includes all message digests and hands ntpq a sorted digest-list.
ntpq doesn't check return from EVP_Digest(Init|Final) and assumes all is well and sticks all digests into its list regardless if it is working or not.
i.e.
ntpq> help keytype
function: set key type to use for authenticated requests, one of:
MD4, MD5, RIPEMD160, SHA1, SHAKE128
If somehow openssl library is corrupted and sends back erroneous results, its possible the authentication will just not ever work.
Newly fixed archive ntpq + oenssl beahviour:
openssl includes all message digests and hands ntpq a sorted digest-list.
ntpq checks each one and includes each working digest. With a non-corrupted openssl, everything works fine and ntpq includes each into its list. Ends up with a list identical to the one above.
If somehow opensll library is corrupted and sends back erroneous results, ntpq will hopefully catch it by checking return code and include only those algos that appear to be working. Its possible authentication will work for ntpq.
The difference will be seen in ntpq + fips-openssl. ntpq will check return, and for fips-not-approved algos, return will indicate an error. So these algos will be skipped and ntpq will not include into its digest list. Resulting in a much shorter list of only fips-approved algos.
i.e.
ntpq> help keytype
function: set key type to use for authenticated requests, one of:
SHA1, SHAKE128
Since md5 is ntpq's default auth algo, this will need to be changed to one of the above algos in the config files.
But I think it is somewhat understood that MD5 is bad in a FIPS environment. |
[Impact]
In FIPS mode on Bionic MD5 is semi-disabled causing some applications to segfault.
ntpq uses crypto hashes to authenticate its requests. By default it uses md5. However, when compiled with openssl it creates a lists of acceptable hashes from openssl that can be used.
This issue is only applicable in bionic when using fips-openssl.
[Test Steps]
Test case:
sudo apt install ntp
ntpq -p
Segmentation fault (core dumped)
What happens there is ntpq wants to iterate all available digests (list_digest_names in ntpq.c). It uses EVP_MD_do_all_sorted for this task.
EVP_MD_do_all_sorted eventually runs openssl_add_all_digests_int in c_alld.c.
For FIPS mode it adds:
EVP_add_digest(EVP_md5());
What happens later in ntpq is (list_md_fn function inside ntpq.c):
ctx = EVP_MD_CTX_new();
EVP_DigestInit(ctx, EVP_get_digestbyname(name));
EVP_DigestFinal(ctx, digest, &digest_len);
First digest it gets is MD5, but while running EVP_DigestInit for it, it gets to this point (openssl/crypto/evp/digest.c EVP_DigestInit_ex):
#ifdef OPENSSL_FIPS
if (FIPS_mode()) {
if (!(type->flags & EVP_MD_FLAG_FIPS)
&& !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW)) {
EVPerr(EVP_F_EVP_DIGESTINIT_EX, EVP_R_DISABLED_FOR_FIPS);
return 0;
}
}
#endif
Due to type->flags for MD5 being 0 there's an error set (EVP_R_DISABLED_FOR_FIPS).
After getting back to ntpq.c:
ctx->engine and ctx->digest are not set (due to the mentioned error), hence
inside EVP_DigestFinal_ex (openssl/crypto/evp/digest.c)
OPENSSL_assert(ctx->digest->md_size <= EVP_MAX_MD_SIZE);
causes a segfault (ctx->digest is NULL).
So either MD5 shouldn't be added in FIPS mode or it should have the EVP_MD_FLAG_FIPS to be properly initialized.
[Regression Potential]
I don't think this should regress ntpq + openssl from the Ubuntu archive.
Current archive ntpq + openssl behaviour:
openssl includes all message digests and hands ntpq a sorted digest-list.
ntpq doesn't check return from EVP_Digest(Init|Final) and assumes all is well and sticks all digests into its list regardless if it is working or not.
i.e.
ntpq> help keytype
function: set key type to use for authenticated requests, one of:
MD4, MD5, RIPEMD160, SHA1, SHAKE128
If somehow openssl library is corrupted and sends back erroneous results, its possible the authentication will just not ever work.
Newly fixed archive ntpq + oenssl beahviour:
openssl includes all message digests and hands ntpq a sorted digest-list.
ntpq checks each one and includes each working digest. With a non-corrupted openssl, everything works fine and ntpq includes each into its list. Ends up with a list identical to the one above.
If somehow opensll library is corrupted and sends back erroneous results, ntpq will hopefully catch it by checking return code and include only those algos that appear to be working. Its possible authentication will work for ntpq.
The difference will be seen in ntpq + fips-openssl. ntpq will check return, and for fips-not-approved algos, return will indicate an error. So these algos will be skipped and ntpq will not include into its digest list. Resulting in a much shorter list of only fips-approved algos.
i.e.
ntpq> help keytype
function: set key type to use for authenticated requests, one of:
SHA1, SHAKE128
Since md5 is ntpq's default auth algo, this will need to be changed to one of the above algos in the config files.
But I think it is somewhat understood that MD5 is bad in a FIPS environment. |
|
| 2020-07-14 20:16:38 |
Joy Latten |
description |
[Impact]
In FIPS mode on Bionic MD5 is semi-disabled causing some applications to segfault.
ntpq uses crypto hashes to authenticate its requests. By default it uses md5. However, when compiled with openssl it creates a lists of acceptable hashes from openssl that can be used.
This issue is only applicable in bionic when using fips-openssl.
[Test Steps]
Test case:
sudo apt install ntp
ntpq -p
Segmentation fault (core dumped)
What happens there is ntpq wants to iterate all available digests (list_digest_names in ntpq.c). It uses EVP_MD_do_all_sorted for this task.
EVP_MD_do_all_sorted eventually runs openssl_add_all_digests_int in c_alld.c.
For FIPS mode it adds:
EVP_add_digest(EVP_md5());
What happens later in ntpq is (list_md_fn function inside ntpq.c):
ctx = EVP_MD_CTX_new();
EVP_DigestInit(ctx, EVP_get_digestbyname(name));
EVP_DigestFinal(ctx, digest, &digest_len);
First digest it gets is MD5, but while running EVP_DigestInit for it, it gets to this point (openssl/crypto/evp/digest.c EVP_DigestInit_ex):
#ifdef OPENSSL_FIPS
if (FIPS_mode()) {
if (!(type->flags & EVP_MD_FLAG_FIPS)
&& !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW)) {
EVPerr(EVP_F_EVP_DIGESTINIT_EX, EVP_R_DISABLED_FOR_FIPS);
return 0;
}
}
#endif
Due to type->flags for MD5 being 0 there's an error set (EVP_R_DISABLED_FOR_FIPS).
After getting back to ntpq.c:
ctx->engine and ctx->digest are not set (due to the mentioned error), hence
inside EVP_DigestFinal_ex (openssl/crypto/evp/digest.c)
OPENSSL_assert(ctx->digest->md_size <= EVP_MAX_MD_SIZE);
causes a segfault (ctx->digest is NULL).
So either MD5 shouldn't be added in FIPS mode or it should have the EVP_MD_FLAG_FIPS to be properly initialized.
[Regression Potential]
I don't think this should regress ntpq + openssl from the Ubuntu archive.
Current archive ntpq + openssl behaviour:
openssl includes all message digests and hands ntpq a sorted digest-list.
ntpq doesn't check return from EVP_Digest(Init|Final) and assumes all is well and sticks all digests into its list regardless if it is working or not.
i.e.
ntpq> help keytype
function: set key type to use for authenticated requests, one of:
MD4, MD5, RIPEMD160, SHA1, SHAKE128
If somehow openssl library is corrupted and sends back erroneous results, its possible the authentication will just not ever work.
Newly fixed archive ntpq + oenssl beahviour:
openssl includes all message digests and hands ntpq a sorted digest-list.
ntpq checks each one and includes each working digest. With a non-corrupted openssl, everything works fine and ntpq includes each into its list. Ends up with a list identical to the one above.
If somehow opensll library is corrupted and sends back erroneous results, ntpq will hopefully catch it by checking return code and include only those algos that appear to be working. Its possible authentication will work for ntpq.
The difference will be seen in ntpq + fips-openssl. ntpq will check return, and for fips-not-approved algos, return will indicate an error. So these algos will be skipped and ntpq will not include into its digest list. Resulting in a much shorter list of only fips-approved algos.
i.e.
ntpq> help keytype
function: set key type to use for authenticated requests, one of:
SHA1, SHAKE128
Since md5 is ntpq's default auth algo, this will need to be changed to one of the above algos in the config files.
But I think it is somewhat understood that MD5 is bad in a FIPS environment. |
[Impact]
In FIPS mode on Bionic MD5 is semi-disabled causing some applications to segfault.
ntpq uses crypto hashes to authenticate its requests. By default it uses md5. However, when compiled with openssl it creates a lists of acceptable hashes from openssl that can be used.
This issue is only applicable in bionic and when using fips-openssl.
[Test Steps]
Test case:
sudo apt install ntp
ntpq -p
Segmentation fault (core dumped)
What happens there is ntpq wants to iterate all available digests (list_digest_names in ntpq.c). It uses EVP_MD_do_all_sorted for this task.
EVP_MD_do_all_sorted eventually runs openssl_add_all_digests_int in c_alld.c.
For FIPS mode it adds:
EVP_add_digest(EVP_md5());
What happens later in ntpq is (list_md_fn function inside ntpq.c):
ctx = EVP_MD_CTX_new();
EVP_DigestInit(ctx, EVP_get_digestbyname(name));
EVP_DigestFinal(ctx, digest, &digest_len);
First digest it gets is MD5, but while running EVP_DigestInit for it, it gets to this point (openssl/crypto/evp/digest.c EVP_DigestInit_ex):
#ifdef OPENSSL_FIPS
if (FIPS_mode()) {
if (!(type->flags & EVP_MD_FLAG_FIPS)
&& !(ctx->flags & EVP_MD_CTX_FLAG_NON_FIPS_ALLOW)) {
EVPerr(EVP_F_EVP_DIGESTINIT_EX, EVP_R_DISABLED_FOR_FIPS);
return 0;
}
}
#endif
Due to type->flags for MD5 being 0 there's an error set (EVP_R_DISABLED_FOR_FIPS).
After getting back to ntpq.c:
ctx->engine and ctx->digest are not set (due to the mentioned error), hence
inside EVP_DigestFinal_ex (openssl/crypto/evp/digest.c)
OPENSSL_assert(ctx->digest->md_size <= EVP_MAX_MD_SIZE);
causes a segfault (ctx->digest is NULL).
So either MD5 shouldn't be added in FIPS mode or it should have the EVP_MD_FLAG_FIPS to be properly initialized.
[Regression Potential]
I don't think this should regress ntpq + openssl from the Ubuntu archive.
Current archive ntpq + openssl behaviour:
openssl includes all message digests and hands ntpq a sorted digest-list.
ntpq doesn't check return from EVP_Digest(Init|Final) and assumes all is well and sticks all digests into its list regardless if it is working or not.
i.e.
ntpq> help keytype
function: set key type to use for authenticated requests, one of:
MD4, MD5, RIPEMD160, SHA1, SHAKE128
If somehow openssl library is corrupted and sends back erroneous results, its possible the authentication will just not ever work.
Newly fixed archive ntpq + oenssl beahviour:
openssl includes all message digests and hands ntpq a sorted digest-list.
ntpq checks each one and includes each working digest. With a non-corrupted openssl, everything works fine and ntpq includes each into its list. Ends up with a list identical to the one above.
If somehow opensll library is corrupted and sends back erroneous results, ntpq will hopefully catch it by checking return code and include only those algos that appear to be working. Its possible authentication will work for ntpq.
The difference will be seen in ntpq + fips-openssl. ntpq will check return, and for fips-not-approved algos, return will indicate an error. So these algos will be skipped and ntpq will not include into its digest list. Resulting in a much shorter list of only fips-approved algos.
i.e.
ntpq> help keytype
function: set key type to use for authenticated requests, one of:
SHA1, SHAKE128
Since md5 is ntpq's default auth algo, this will need to be changed to one of the above algos in the config files.
But I think it is somewhat understood that MD5 is bad in a FIPS environment. |
|
| 2020-07-17 16:30:43 |
Marc Deslauriers |
openssl (Ubuntu Bionic): status |
Confirmed |
In Progress |
|
| 2020-07-17 16:30:52 |
Marc Deslauriers |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-07-22 14:44:59 |
Dariusz Gadomski |
bug task added |
|
ntp (Ubuntu) |
|
| 2020-07-28 20:38:30 |
Brian Murray |
openssl (Ubuntu): status |
In Progress |
Fix Released |
|
| 2020-07-28 20:38:41 |
Brian Murray |
ntp (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2020-07-28 20:38:44 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2020-07-28 20:38:48 |
Brian Murray |
tags |
sts |
sts verification-needed verification-needed-bionic |
|
| 2020-07-29 15:28:04 |
Dariusz Gadomski |
tags |
sts verification-needed verification-needed-bionic |
sts verification-done verification-done-bionic |
|
| 2020-08-04 08:04:12 |
Launchpad Janitor |
ntp (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2020-08-04 08:04:16 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2020-08-18 17:24:12 |
Steve Beattie |
ntp (Ubuntu): status |
New |
Invalid |
|
| 2020-08-18 17:24:54 |
Steve Beattie |
openssl (Ubuntu Bionic): status |
In Progress |
Invalid |
|
