Debian-LTS has issued an advisory on May 5: https://www.debian.org/lts/security/2020/dla-2201 The issue is fixed upstream in 4.2.8p14, which fixes two other security issues: http://support.ntp.org/bin/view/Main/SecurityNotice#March_2020_ntp_4_2_8p14_NTP_Rele Mageia 7 is also affected.
Status comment: (none) => Fixed upstream in 4.2.8p14Whiteboard: (none) => MGA7TOO
ntp ha no registered nor regular maintainer, so assigning this globally. CC'ing NicolasS who has updated it in the past.
Assignee: bugsquad => pkg-bugsCC: (none) => nicolas.salguero
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)Assignee: pkg-bugs => qa-bugsStatus: NEW => ASSIGNEDCVE: (none) => CVE-2020-11868Status comment: Fixed upstream in 4.2.8p14 => (none)Source RPM: ntp-4.2.8p13-2.mga8.src.rpm => ntp-4.2.8p13-1.mga7.src.rpmVersion: Cauldron => 7
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
CC: (none) => tmbKeywords: (none) => advisory
(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_updateCC: (none) => davidwhodgins, sysadmin-bugs
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) => FIXEDStatus: ASSIGNED => RESOLVED
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