[Touch-packages] [Bug 1884265] Re: [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl library.
Closing ntp task for groovy.
** Changed in: ntp (Ubuntu)
Status: New => Invalid
** Changed in: openssl (Ubuntu Bionic)
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1884265
Title:
[fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl
library.
Status in ntp package in Ubuntu:
Invalid
Status in openssl package in Ubuntu:
Fix Released
Status in ntp source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
Invalid
Bug 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 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, _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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1884265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1884265] Re: [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl library.
This bug was fixed in the package ntp - 1:4.2.8p10+dfsg-5ubuntu7.2
---
ntp (1:4.2.8p10+dfsg-5ubuntu7.2) bionic; urgency=medium
* ntpq should check return code from libcrypto calls (LP: #1884265)
- debian/patches/ntpq-openssl-check.patch
-- Joy Latten Thu, 09 Jul 2020 21:11:52
+
** Changed in: ntp (Ubuntu Bionic)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1884265
Title:
[fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl
library.
Status in ntp package in Ubuntu:
New
Status in openssl package in Ubuntu:
Fix Released
Status in ntp source package in Bionic:
Fix Released
Status in openssl source package in Bionic:
In Progress
Bug 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 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, _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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1884265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1884265] Re: [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl library.
I have verified it for Bionic using ntp 1:4.2.8p10+dfsg-5ubuntu7.2.
No segfault observed:
sudo ntpq -p
remote refid st t when poll reach delay offset jitter
==
0.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
1.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
2.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
3.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
ntp.ubuntu.com .POOL. 16 p - 64 0 0.000 0.000 0.000
+tel50.oa.uj.edu 149.156.70.75 2 u 6 64 1 14.404 0.782 0.386
*SunSITE.icm.edu 210.100.177.101 2 u 5 64 1 12.239 0.138 0.645
(...)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1884265
Title:
[fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl
library.
Status in ntp package in Ubuntu:
New
Status in openssl package in Ubuntu:
Fix Released
Status in ntp source package in Bionic:
Fix Committed
Status in openssl source package in Bionic:
In Progress
Bug 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 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, _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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1884265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post
[Touch-packages] [Bug 1884265] Re: [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl library.
I have verified it for Bionic using ntp 1:4.2.8p10+dfsg-5ubuntu7.2.
No segfault observed:
sudo ntpq -p
remote refid st t when poll reach delay offset jitter
==
0.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.000
1.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.000
2.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.000
3.ubuntu.pool.n .POOL. 16 p- 6400.0000.000 0.000
ntp.ubuntu.com .POOL. 16 p- 6400.0000.000 0.000
+tel50.oa.uj.edu 149.156.70.752 u6 641 14.4040.782 0.386
*SunSITE.icm.edu 210.100.177.101 2 u5 641 12.2390.138 0.645
+46.175.224.7.ma 178.252.19.225 3 u5 641 35.6070.018 0.661
+news-archive.ic 229.30.220.210 2 u3 6419.9420.135 0.761
-afrodyta.comple 210.100.177.101 2 u1 641 14.6961.299 0.648
ntp11.kashra-se 192.168.100.15 2 u1 641 35.386 -3.146 0.297
-time.taken.pl 80.50.231.2262 u1 6419.1331.390 0.282
-ntp.tktelekom.p 80.50.231.2262 u1 6418.8390.079 0.569
-ntp.wide-net.pl 194.146.251.101 2 u4 641 16.7390.559 0.324
-icemen.pl 17.253.52.2532 u4 641 34.257 -0.985 0.550
96-7.cpe.smnt.p 5.226.98.186 2 u- 641 14.709 -0.850 0.860
-ntp.ifj.edu.pl 213.222.200.99 2 u2 641 30.4639.168 0.457
pugot.canonical 17.253.34.1252 u 13 641 41.787 -3.423 0.000
ntp2.tktelekom. 212.160.106.226 2 u- 6419.2110.220 0.907
alphyn.canonica 132.163.97.1 2 u 12 641 113.404 -3.408 0.000
time.cloudflare 10.71.10.44 3 u- 641 23.523 -1.134 0.748
golem.canonical 140.203.204.77 2 u 11 641 41.912 -2.097 0.00
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1884265
Title:
[fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl
library.
Status in ntp package in Ubuntu:
New
Status in openssl package in Ubuntu:
Fix Released
Status in ntp source package in Bionic:
Fix Committed
Status in openssl source package in Bionic:
In Progress
Bug 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 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, _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
[Touch-packages] [Bug 1884265] Re: [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl library.
Hello Dariusz, or anyone else affected,
Accepted ntp into bionic-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/ntp/1:4.2.8p10+dfsg-
5ubuntu7.2 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Changed in: openssl (Ubuntu)
Status: In Progress => Fix Released
** Changed in: ntp (Ubuntu Bionic)
Status: New => Fix Committed
** Tags added: verification-needed verification-needed-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1884265
Title:
[fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl
library.
Status in ntp package in Ubuntu:
New
Status in openssl package in Ubuntu:
Fix Released
Status in ntp source package in Bionic:
Fix Committed
Status in openssl source package in Bionic:
In Progress
Bug 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 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, _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
[Touch-packages] [Bug 1884265] Re: [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl library.
** Also affects: ntp (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1884265
Title:
[fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl
library.
Status in ntp package in Ubuntu:
New
Status in openssl package in Ubuntu:
In Progress
Status in ntp source package in Bionic:
New
Status in openssl source package in Bionic:
In Progress
Bug 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 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, _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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1884265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1884265] Re: [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl library.
ACK on the debdiff in comment #11, uploaded with a slight LP tag fix for
processing by the SRU team. Thanks!
** Changed in: openssl (Ubuntu Bionic)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1884265
Title:
[fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl
library.
Status in openssl package in Ubuntu:
In Progress
Status in openssl source package in Bionic:
In Progress
Bug 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 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, _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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1884265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1884265] Re: [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl library.
** Description changed:
[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, _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.
+ 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.
+ i.e.
ntpq> help keytype
function: set key type to use for authenticated requests, one of:
- MD4, MD5, RIPEMD160, SHA1, SHAKE128
+ 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.
+
+ 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
+ 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.
+ 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.
** Description changed:
[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.
+ 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
[Touch-packages] [Bug 1884265] Re: [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl library.
** Summary changed:
- [fips] Not fully initialized digest segfaulting some client applications
+ [fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl library.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1884265
Title:
[fips] ntpq segfaults when attempting to use MD5 from FIPS-openssl
library.
Status in openssl package in Ubuntu:
In Progress
Status in openssl source package in Bionic:
Confirmed
Bug 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, _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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1884265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
