Bug 1955859 - CVE-2021-22212 ntpsec: ntpkeygen generates weak keys [fedora-34]
Summary: CVE-2021-22212 ntpsec: ntpkeygen generates weak keys [fedora-34]
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ntpsec
Version: 34
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Miroslav Lichvar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1975415 (view as bug list)
Depends On:
Blocks: CVE-2021-22212
TreeView+ depends on / blocked
 
Reported: 2021-05-01 02:09 UTC by Maciej Żenczykowski
Modified: 2021-06-26 01:00 UTC (History)
3 users (show)

Fixed In Version: ntpsec-1.2.1-3.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-26 01:00:47 UTC
Type: Bug


Attachments (Terms of Use)

Description Maciej Żenczykowski 2021-05-01 02:09:41 UTC
This is a regression from ntpd in fc33

Installed Packages:
  ntp-refclock.x86_64  0.4-3.fc34
  ntpsec.x86_64        1.2.0-6.fc34
  ntpstat.noarch       0.6-4.fc34

ntpd[1173]: IO: Listening on routing socket on fd #23 for interface updates
ntpd[1173]: INIT: ntpd was compiled without refclock support.
ntpd[1173]: PROTO: 127.127.1.0 unlink local addr 127.0.0.1 -> <null>
ntpd[1173]: INIT: ntpd was compiled without refclock support.
ntpd[1173]: PROTO: 127.127.20.0 unlink local addr 127.0.0.1 -> <null>
ntpd[1173]: CONFIG: Fudge commands not supported: built without refclocks

I've found and installed the 'ntp-refclock' package, but it doesn't seem to help.
I don't see any obviously correct packages to install, searching for pps nmea gps refclock...

Comment 1 Maciej Żenczykowski 2021-05-01 02:13:10 UTC
https://fedoraproject.org/wiki/Changes/NtpReplacement makes no mention of how to make things work.

Comment 2 Maciej Żenczykowski 2021-05-01 08:46:16 UTC
Downgrading to ntp/ntpdate 4.2.8p15-3.fc33 fixes the problem (unsurprisingly),
though along the way it deleted my ntp crypto keys and I had to recover them from backups or regenerate them.

Comment 3 Maciej Żenczykowski 2021-05-03 07:38:42 UTC
Unpacking the source ntpsec tarball finds the following in INSTALL.adoc:

== Optional Features ==

The waf builder accepts `--enable-FEATURE` options to where FEATURE
indicates an optional part of the package.  Do `waf --help` for a list
of options.

refclocks are enabled with `--refclock=<n1,n2,n3..>` or `--refclock=all`
`waf configure --list` will print a list of available refclocks.

---

So adding --refclock=local,nmea to the ntpsec.spec file and rebuilding.
(though perhaps it should just be --refclock=all)

This seems to produce a closer to functional package.

May 02 23:38:24 mini.lan ntpd[29966]: REFCLOCK: refclock_params: kernel PLL (hardpps, RFC 1589) not implemented
May 02 23:38:24 mini.lan ntpd[29966]: REFCLOCK: NMEA(0) set PPSAPI params fails

which can be fixed (worked around?) by flipping 'flag3 1' to 'flag3 0' though that seems suboptimal.
Presumably this is something missing from ntpsec that was present in fc33 ntpd?

---

Note: I also have extra selinux config localntp.te:

module localntp 1.0;

require {
	type clock_device_t;
	type ntpd_t;
	type tty_device_t;
	class lnk_file read;
	class chr_file { open read write ioctl };
}

#============= ntpd_t ==============
allow ntpd_t tty_device_t:lnk_file read;
allow ntpd_t tty_device_t:chr_file { open read write ioctl };
allow ntpd_t clock_device_t:lnk_file read;
allow ntpd_t clock_device_t:chr_file { open read write ioctl };

which I'm not entirely sure if it is still needed or not.

---

Another thing that comes to light is that apparently /usr/bin/ntpkeygen can generate keys which fail to parse.

cd /etc/ntp && ntpkeygen && ln -sf ntp.keys keys && systemctl status restart

May 03 00:02:15 mini.lan ntpd[30661]: AUTH: authreadkeys: reading /etc/ntp/keys
May 03 00:02:15 mini.lan ntpd[30661]: AUTH: CMAC key 8 will be padded 10=>16
May 03 00:02:15 mini.lan ntpd[30661]: AUTH: authreadkeys: added 20 keys

This appears to be related to the presence of #'s in the key:
 8 AES yaFV<<}Z4x#n^k,#

May 03 00:10:14 mini.lan ntpd[30802]: AUTH: authreadkeys: reading /etc/ntp/keys
May 03 00:10:14 mini.lan ntpd[30802]: AUTH: CMAC key 10 will be padded 8=>16
May 03 00:10:14 mini.lan ntpd[30802]: AUTH: authreadkeys: added 20 keys

10 AES Nc{2&pyv#C}=,KqN

May 03 00:11:53 mini.lan ntpd[30857]: AUTH: authreadkeys: reading /etc/ntp/keys
May 03 00:11:53 mini.lan ntpd[30857]: AUTH: authreadkeys: no key for key 9
May 03 00:11:53 mini.lan ntpd[30857]: AUTH: authreadkeys: added 19 keys

 9 AES #CeE{.3qv(,:.e.G

btw. additionally 'man ntpkeygen' has a tiny typo since it lists [-MV] instead of [-V]

Comment 4 Miroslav Lichvar 2021-05-03 08:23:36 UTC
Thanks for the report.

I'll make an update enabling the refclock support. I didn't notice it's disabled by default.
I'll look into the keygen issue.

The hardpps feature requires a special build of the kernel. It didn't work with the old ntpd either.

If you find any selinux issues, please file a bug for the selinux-policy component.

Comment 5 Fedora Update System 2021-06-07 11:20:01 UTC
FEDORA-2021-3ffc890685 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3ffc890685

Comment 6 Maciej Żenczykowski 2021-06-07 21:00:13 UTC
Okay, that seems to fix the refclock missing problem, and the 'man ntpkeygen' showing [-MV] instead of [-V] but trunc issue remains:

Jun 07 13:53:14 mini.lan ntpd[9716]: INIT: ntpd ntpsec-1.2.1: Starting
Jun 07 13:53:14 mini.lan ntpd[9716]: INIT: Command line: /usr/sbin/ntpd -g -N -u ntp:ntp
Jun 07 13:53:14 mini.lan ntpd[9716]: 2021-06-07T13:53:14 ntpd[9716]: INIT: ntpd ntpsec-1.2.1: Starting
Jun 07 13:53:14 mini.lan ntpd[9716]: 2021-06-07T13:53:14 ntpd[9716]: INIT: Command line: /usr/sbin/ntpd -g -N -u n>
Jun 07 13:53:14 mini.lan ntpd[9717]: INIT: precision = 2.654 usec (-18)
Jun 07 13:53:14 mini.lan ntpd[9717]: INIT: successfully locked into RAM
Jun 07 13:53:14 mini.lan ntpd[9717]: CONFIG: readconfig: parsing file: /etc/ntp.conf
Jun 07 13:53:14 mini.lan ntpd[9717]: AUTH: authreadkeys: reading /etc/ntp/crypto/ntp.keys
Jun 07 13:53:14 mini.lan ntpd[9717]: AUTH: CMAC key 2 will be padded 12=>16
Jun 07 13:53:14 mini.lan ntpd[9717]: AUTH: CMAC key 4 will be padded 15=>16
Jun 07 13:53:14 mini.lan ntpd[9717]: AUTH: CMAC key 6 will be padded 3=>16
Jun 07 13:53:14 mini.lan ntpd[9717]: AUTH: authreadkeys: added 20 keys

Comment 7 Maciej Żenczykowski 2021-06-07 21:09:33 UTC
Actually the problem appears to have been fixed in 'ntpkeygen' (and not ntpd itself).
So if you regenerate the ntp.keys file with ntpkeygen it no longer outputs keys that ntpd cannot parse.
I guess that's good enough?
Provided people regenerate their keys.

Comment 8 Miroslav Lichvar 2021-06-08 07:43:25 UTC
Yes, users need to check their keys and regenerate them (or manually fix) if they contain the hash symbol. The update description mentions this, but I'm not sure how many people actually read those.

Comment 9 Maciej Żenczykowski 2021-06-08 08:59:05 UTC
Probably no one.
I wouldn't even know where to look (nor that there is such a thing for Fedora as opposed to RHEL).
Most probably just run 'dnf update' or equivalent.

Comment 10 Miroslav Lichvar 2021-06-08 09:55:01 UTC
I guess you are right.

Would it make sense to add a script that would check the keyfile and prevent ntpd from starting if it finds a key that includes the hash? Or just emit a warning? I'm not sure if a non-functional service is better than an insecure one, but at least it would bring the attention of the admin.

Comment 11 Maciej Żenczykowski 2021-06-08 15:24:29 UTC
It could perhaps just
  sed -i -r '/^ *[0-9]+ AES .*#/d'
out the lines (or something like that)...

The problem is the location of the file is not exactly well defined, so I guess you'd have to parse the ntpd config file to find it - and possibly includes?

I think perhaps the easiest thing is to simply modify ntpd to ignore keys instead of padding them?
(or if ignoring is hard, just pad with random bits, which will basically make those keys useless, but not guessable)

Comment 12 Fedora Update System 2021-06-09 01:16:06 UTC
FEDORA-2021-3ffc890685 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3ffc890685`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3ffc890685

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 13 Maciej Żenczykowski 2021-06-09 03:05:20 UTC
I'd grant it positive karma (since I've installed it locally and it's working fine), but the login server on bodhi isn't working (returns a "500 Internal Server Error   Could not convert return value of the view callable function pyramid_fas_openid.view.verify_openid into a response object. The value returned was None. You may have forgotten to return a value from the view callable.").

Comment 14 Miroslav Lichvar 2021-06-09 07:42:10 UTC
Don't give it karma if you think the update needs some work.

I wish upstream provided some guidance for users and downstream maintainers.

I don't see a reliable way to detect the broken keys. '#' just starts a comment and maybe someone used it on purpose, right next to the actual key without any whitespace, e.g.

1 AES &qAt?7^mTooHz9JK#this is a comment

How do we detect a real comment?

We could check the length of the key, but what would be the threshold? People might be using a shorter key intentionally. A short key is still better than no key at all and we don't want to break a working configuration just because we suspect the key was generated by ntpkeygen, right? Also, I'd rather avoid downstream-specific patches.

Comment 15 Maciej Żenczykowski 2021-06-09 08:04:00 UTC
Well, I'd give positive karma if I could, because it's already better then the current stable package. :-)

Honestly ignoring all truncated keys seems fine to me - I kind of doubt anyone generates them via something besides ntpkeygen - I don't think the format is even documented anywhere - is it?...
(and ntpd already logs when it hits truncated keys, so it knows they're 'bad')

I assume currently such truncated keys are simply padded with 0s...

Though I don't really understand how this apparent base~90-ish encoding of keys works.
Seems very very weird.

Anyway, it's probably fine as is.  NTP crypto is probably used rarely enough as is,
and even rarer on bleeding edge Fedora rather than RHEL.
I'm using this on a dev box for playing around with some time stuff.

Comment 16 Miroslav Lichvar 2021-06-09 08:24:21 UTC
As I understand it, the original format of the key file was just plain text passwords. It was later extended to parse strings longer than 20 characters as HEX-encoded values to better suit SHA1 and stronger hash functions. ntpkeygen generates two sets of 128-bit keys, using both formats. The latter would be recommended for everyone, but some people might still be putting manually written passwords there. I don't know.

Only AES keys require padding. The older types like MD5, SHA1, SHA256 are ok with any key length.

Comment 17 Miroslav Lichvar 2021-06-10 07:31:24 UTC
Changing the summary to the security issue, now that it's the main point of this bug.

Comment 18 Miroslav Lichvar 2021-06-17 10:44:38 UTC
I got a suggestion from the security response team to detect comments that are not separated from the key by the space or tab character. If such a key is detected, ntpd will exit to force the admin to fix the file. False positives are possible, but they should be rare and it is probably better than running with a weak key. This issue was only in Fedora 34. After few releases, we can consider dropping the patch.

Comment 19 Fedora Update System 2021-06-17 11:06:18 UTC
FEDORA-2021-3ffc890685 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3ffc890685

Comment 20 Fedora Update System 2021-06-18 01:21:28 UTC
FEDORA-2021-3ffc890685 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3ffc890685`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3ffc890685

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 21 George Joseph 2021-06-23 16:45:57 UTC
*** Bug 1975415 has been marked as a duplicate of this bug. ***

Comment 22 Fedora Update System 2021-06-26 01:00:47 UTC
FEDORA-2021-3ffc890685 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.