Additional testing for ntpq authentication to ensure MD5 still works for
ntpq in archive
NOTE: The shown testing is ntpq(with patch) + openssl from archive. To ensure
all still works.
Testing with ntpq + fips-openssl was also done successfully.
VM-A (ntp server)
1. Edit /etc/ntp.keys to include,
1 SHA1 austintexas
2 MD5 cedarpark
2. Edit /etc/ntp.conf to include.
keys /etc/ntp.keys
trustedkey 2
controlkey 2
requestkey 2
3. restart ntp
sudo service ntp restart
VM-B (ntp client)
$ dpkg -l | grep ntp
ii ntp 1:4.2.8p10+dfsg-5ubuntu7.1+ppa1
amd64 Network Time Protocol daemon and utility programs
1. Edit /etc/ntp.keys to include,
1 SHA1 austintexas
2 MD5 cedarpark
2. Edit /etc/ntp.conf to include,
keys /etc/ntp.keys
server <VM-B ipaddress> key 2
trustedkey 2
controlkey 2
requestkey 2
3. I commented out all the "pool" entries in /etc/ntp.conf
4. restart ntp
sudo service ntp restart
On the client,
$ ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 46728 f014 yes yes ok reject reachable 1
Notice that "auth" is ok.
$ ntpq
ntpq> keytype
keytype is MD5 with 16 octet digests
ntpq> keyid 2
ntpq> ifstats
MD5 Password: <enter "cedarpark">
interface name send
# address/broadcast drop flag ttl mc received sent failed peers uptime
==============================================================================
0 v6wildcard D 81 0 0 0 0 0 0 96
[::]:123
1 v4wildcard D 89 0 0 0 0 0 0 96
0.0.0.0:123
2 lo . 5 0 0 2 1 0 0 96
127.0.0.1:123
3 ens3 . 19 0 0 2 2 0 1 96
192.168.122.105:123
4 lo . 5 0 0 0 0 0 0 96
[::1]:123
5 ens3 . 11 0 0 0 0 0 0 96
[fe80::5054:ff:fefe:b092%2]:123
ntpq>
Note: issuing "ifstats" requires authentication.
I also tested with SHA1 and it worked as well.
And last test on client,
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.122.106 204.11.201.12 3 u 56 64 7 1.541 2.723 0.826
--
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] Not fully initialized digest segfaulting some client
applications
Status in openssl package in Ubuntu:
New
Status in openssl source package in Bionic:
New
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, &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
