| Summary: | ntp new security issues CVE-2020-11868 and CVE-2020-13817 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Sec team <security> |
| Severity: | major | ||
| Priority: | Normal | CC: | davidwhodgins, herman.viaene, mageia, nicolas.salguero, sysadmin-bugs, tarazed25, tmb |
| Version: | 7 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA7-64-OK | ||
| Source RPM: | ntp-4.2.8p13-1.mga7.src.rpm | CVE: | CVE-2020-11868 |
| Status comment: | |||
|
Description
David Walser
2020-05-06 20:21:38 CEST
David Walser
2020-05-06 20:21:53 CEST
Status comment:
(none) =>
Fixed upstream in 4.2.8p14 ntp ha no registered nor regular maintainer, so assigning this globally. CC'ing NicolasS who has updated it in the past. Assignee:
bugsquad =>
pkg-bugs Suggested advisory: ======================== The updated packages fix security vulnerabilities including: ntpd in ntp before 4.2.8p14 and 4.3.x before 4.3.100 allows an off-path attacker to block unauthenticated synchronization via a server mode packet with a spoofed source IP address, because transmissions are rescheduled even when a packet lacks a valid origin timestamp. (CVE-2020-11868) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11868 https://www.debian.org/lts/security/2020/dla-2201 http://support.ntp.org/bin/view/Main/SecurityNotice#March_2020_ntp_4_2_8p14_NTP_Rele ======================== Updated packages in core/updates_testing: ======================== ntp-4.2.8p14-1.mga7 ntp-perl-4.2.8p14-1.mga7 ntpdate-4.2.8p14-1.mga7 sntp-4.2.8p14-1.mga7 ntp-doc-4.2.8p14-1.mga7 from SRPMS: ntp-4.2.8p14-1.mga7.src.rpm Whiteboard:
MGA7TOO =>
(none) MGA7-64 Plasma on Lenovo B50 No installation issues. I don't get it. There was no previous ntp package installed, although I'm damned sure I set the time zone and ntp at installation time. Tried to initialize it in MCC, but on applying, the MCC hangs And then at CLI: # ps -aux | grep ntpd root 19368 0.0 0.0 9044 812 pts/1 S+ 11:09 0:00 grep --color ntpd root 20517 0.0 0.0 74280 4536 ? S 11:01 0:00 /usr/sbin/ntpd -gqc /dev/null be.pool.ntp.org That looks good, but # systemctl -l status ntpd ● ntpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2020-05-08 11:04:16 CEST; 5min ago Process: 30484 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS (code=exited, status=1/FAILURE) May 08 11:04:16 mach5.hviaene.thuis ntpd[30484]: available at https://www.nwtime.org/support May 08 11:04:16 mach5.hviaene.thuis ntpd[30484]: ---------------------------------------------------- May 08 11:04:16 mach5.hviaene.thuis ntpd[30486]: proto: precision = 0.075 usec (-24) May 08 11:04:16 mach5.hviaene.thuis ntpd[30486]: basedate set to 2020-04-25 May 08 11:04:16 mach5.hviaene.thuis ntpd[30486]: gps base set to 2020-04-26 (week 2103) May 08 11:04:16 mach5.hviaene.thuis ntpd[30486]: unable to bind to wildcard address :: - another process may be running - > May 08 11:04:16 mach5.hviaene.thuis ntpd[30484]: daemon child exited with code 1 May 08 11:04:16 mach5.hviaene.thuis systemd[1]: ntpd.service: Control process exited, code=exited, status=1/FAILURE May 08 11:04:16 mach5.hviaene.thuis systemd[1]: ntpd.service: Failed with result 'exit-code'. May 08 11:04:16 mach5.hviaene.thuis systemd[1]: Failed to start Network Time Service. CC:
(none) =>
herman.viaene
Thomas Backlund
2020-05-08 12:22:34 CEST
CC:
(none) =>
tmb (In reply to Herman Viaene from comment #3) > MGA7-64 Plasma on Lenovo B50 > I don't get it. > There was no previous ntp package installed, although I'm damned sure I set > the time zone and ntp at installation time. Your system is probably using systemd-timesyncd to sync time using NTP. $ timedatectl status Local time: sex 2020-05-08 14:58:38 CEST Universal time: sex 2020-05-08 12:58:38 UTC RTC time: sex 2020-05-08 12:58:39 Time zone: Europe/Rome (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no $ timedatectl show Timezone=Europe/Rome LocalRTC=no CanNTP=yes NTP=yes NTPSynchronized=yes TimeUSec=Fri 2020-05-08 14:58:41 CEST RTCTimeUSec=Fri 2020-05-08 14:58:42 CEST $ timedatectl timesync-status Server: 216.239.35.0 (time1.google.com) Poll interval: 2min 8s (min: 32s; max 34min 8s) Leap: normal Version: 4 Stratum: 1 Reference: GOOG Precision: 1us (-20) Root distance: 106us (max: 5s) Offset: +1.805ms Delay: 32.947ms Jitter: 1.047ms Packet count: 3 Frequency: +2,539ppm $ systemctl status systemd-timesyncd.service ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2020-05-08 14:56:54 CEST; 2min 50s ago Docs: man:systemd-timesyncd.service(8) Main PID: 607 (systemd-timesyn) Status: "Initial synchronization to time server 216.239.35.0:123 (time1.google.com)." Tasks: 2 (limit: 1158) Memory: 2.0M CGroup: /system.slice/systemd-timesyncd.service └─607 /usr/lib/systemd/systemd-timesyncd mai 08 14:56:53 marte-vm-mageia-7 systemd[1]: Starting Network Time Synchronization... mai 08 14:56:54 marte-vm-mageia-7 systemd[1]: Started Network Time Synchronization. mai 08 14:56:54 marte-vm-mageia-7 systemd-timesyncd[607]: Initial synchronization to time server 216.239.35.0:123 (time1.google.com). CC:
(none) =>
mageia Tx, and tried those:
# timedatectl status
Local time: Sun 2020-05-10 10:12:10 CEST
Universal time: Sun 2020-05-10 08:12:10 UTC
RTC time: Sun 2020-05-10 10:12:11
Time zone: Europe/Brussels (CEST, +0200)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
# timedatectl show
Timezone=Europe/Brussels
LocalRTC=yes
CanNTP=yes
NTP=no
NTPSynchronized=yes
TimeUSec=Sun 2020-05-10 10:12:49 CEST
RTCTimeUSec=Sun 2020-05-10 12:12:50 CEST
# timedatectl timesync-status
Failed to query server: Unit dbus-org.freedesktop.timesync1.service not found.
# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: disabled)
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)
You need to stop chronyd first. Tx David
So now:
# systemctl stop chronyd
# systemctl start systemd-timesyncd.service
# systemctl status -l systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2020-05-13 16:16:33 CEST; 19s ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 1265 (systemd-timesyn)
Status: "Initial synchronization to time server 216.239.35.0:123 (time1.google.com)."
Tasks: 2 (limit: 4915)
Memory: 1.3M
CGroup: /system.slice/systemd-timesyncd.service
└─1265 /usr/lib/systemd/systemd-timesyncd
May 13 16:16:33 mach5.hviaene.thuis systemd[1]: Starting Network Time Synchronization...
May 13 16:16:33 mach5.hviaene.thuis systemd-timesyncd[1265]: The system is configured to read the RTC time in the local ti>
May 13 16:16:33 mach5.hviaene.thuis systemd[1]: Started Network Time Synchronization.
May 13 16:16:33 mach5.hviaene.thuis systemd-timesyncd[1265]: Initial synchronization to time server 216.239.35.0:123 (time>
# timedatectl status
Local time: Wed 2020-05-13 16:17:24 CEST
Universal time: Wed 2020-05-13 14:17:24 UTC
RTC time: Wed 2020-05-13 16:17:26
Time zone: Europe/Brussels (CEST, +0200)
System clock synchronized: no
NTP service: active
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
# timedatectl show
Timezone=Europe/Brussels
LocalRTC=yes
CanNTP=yes
NTP=yes
NTPSynchronized=no
TimeUSec=Wed 2020-05-13 16:17:57 CEST
RTCTimeUSec=Wed 2020-05-13 18:17:59 CEST
# timedatectl timesync-status
Server: 216.239.35.0 (time1.google.com)
Poll interval: 2min 8s (min: 32s; max 34min 8s)
Leap: normal
Version: 4
Stratum: 1
Reference: GOOG
Precision: 1us (-20)
Root distance: 106us (max: 5s)
Offset: -260us
Delay: 18.785ms
Jitter: 98us
Packet count: 2
Frequency: -0.578ppm
That seems OK.Whiteboard:
(none) =>
MGA7-64-OK No, this bug is for ntpd. You shouldn't be running systemd-timesyncd either. To see if ntpd is working, run ntpq and enter the command lpeers. A * will show you which server you are synced with. Waited a few minutes after restarting ntpd.service to allow it to fully resync
the time ...
# ntptime
ntp_gettime() returns code 0 (OK)
time e266e366.67417ca4 Wed, May 13 2020 17:21:42.403, (.403343124),
maximum error 52791 us, estimated error 1289 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 64.005 us, frequency 8.373 ppm, interval 1 s,
maximum error 52791 us, estimated error 1289 us,
status 0x2001 (PLL,NANO),
time constant 10, precision 0.001 us, tolerance 500 ppm,
]# ntpq
ntpq> lpeers
remote refid st t when poll reach delay offset jitter
==============================================================================
*time.nrc.ca 132.246.11.231 2 u 297 1024 377 19.190 +0.065 2.077
ntpq> q
For future testers, note that after restart, while waiting for it to sync the
first line returned from ntptime is ...
tp_gettime() returns code 5 (ERROR)Keywords:
(none) =>
validated_update mga7, x86_64
Carrying this one through, with apologies to Herman.
Thanks to David and Dave and PC LX.
Discovered that network time synchronization was not active.
Installed release packages and checked that ntpd worked using ntpq.
# ntpq
ntpq> lpeers
remote refid st t when poll reach delay offset jitter
==============================================================================
2.fedora.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.000
*time.videxio.ne 194.58.204.20 2 u 53 64 1 24.908 +0.635 0.606
ntpq> quit
Updated the packages and tried again.
# systemctl restart ntpd
# systemctl status ntpd
● ntpd.service - Network Time Service
Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; vendor prese>
Active: active (running) since Thu 2020-05-14 07:03:44 BST; 49s ago
Process: 6196 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS (code=exited, stat>
Main PID: 6198 (ntpd)
Tasks: 2 (limit: 4915)
Memory: 1.1M
CGroup: /system.slice/ntpd.service
└─6198 /usr/sbin/ntpd -u ntp:ntp -g
May 14 07:03:44 difda ntpd[6198]: Listen normally on 2 lo 127.0.0.1:123
May 14 07:03:44 difda ntpd[6198]: Listen normally on 3 enp3s0 192.168.1.103:123
May 14 07:03:44 difda ntpd[6198]: Listen normally on 4 lo [::1]:123
May 14 07:03:44 difda ntpd[6198]: Listen normally on 5 enp3s0 [fe80::dacb:8aff:>
May 14 07:03:44 difda ntpd[6198]: Listening on routing socket on fd #22 for int>
May 14 07:03:44 difda ntpd[6198]: kernel reports TIME_ERROR: 0x2041: Clock Unsy>
May 14 07:03:44 difda ntpd[6198]: kernel reports TIME_ERROR: 0x2041: Clock Unsy>
May 14 07:03:44 difda systemd[1]: Started Network Time Service.
May 14 07:03:45 difda ntpd[6198]: Soliciting pool server 176.58.109.199
May 14 07:03:46 difda ntpd[6198]: Soliciting pool server 85.199.214.101
# ntpq
ntpq> lpeers
remote refid st t when poll reach delay offset jitter
==============================================================================
2.fedora.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.000
*time.videxio.ne 194.58.204.20 2 u 18 64 1 24.889 +0.338 2.117
ntpq> quit
# ntptime
ntp_gettime() returns code 5 (ERROR)
Later:
# ntptime
ntp_gettime() returns code 0 (OK)
time e2676127.442dcf48 Thu, May 14 2020 7:18:15.266, (.266324511),
maximum error 139470 us, estimated error 1364 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 161.973 us, frequency -5.304 ppm, interval 1 s,
maximum error 139470 us, estimated error 1364 us,
status 0x2001 (PLL,NANO),
time constant 6, precision 0.001 us, tolerance 500 ppm,
Looks like it is working.CC:
(none) =>
tarazed25 Looks like you all already knew that. Should have checked the top first. An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0212.html Resolution:
(none) =>
FIXED One of the other upstream bugs fixed in this update that didn't have a CVE at the time (3596) has been assigned CVE-2020-13817: https://access.redhat.com/errata/RHSA-2020:2663 https://bugzilla.redhat.com/show_bug.cgi?id=1811627 Summary:
ntp new security issue CVE-2020-11868 =>
ntp new security issues CVE-2020-11868 and CVE-2020-13817 |