Last update: April 22, 2024 18:49 UTC (7e7bd5857)
| Resolved | 4.2.8p9 | 21 Nov 2016 |
|---|---|---|
| References | Bug 3072 | CVE-2016-7429 |
| Affects | ntp-4.2.7p385, up to but not including ntp-4.2.8p9, and ntp-4.3.0 up to, but not including ntp-4.3.94. |
Resolved in 4.2.8p9. |
| CVSS2 Score | LOW 1.0 | AV:L/AC:H/Au:S/C:N/I:N/A:P |
| CVSS3 Score | LOW 1.6 | CVSS:3.0/AV:P/AC:H/PR:H/UI:R/S:U/C:N/I:N/A:L |
When ntpd receives a server response on a socket that corresponds to a different interface than was used for the request, the peer structure is updated to use the interface for new requests. If ntpd is running on a host with multiple interfaces in separate networks and the operating system doesn’t check source address in received packets (e.g. rp_filter on Linux is set to 0), an attacker that knows the address of the source can send a packet with spoofed source address which will cause ntpd to select wrong interface for the source and prevent it from sending new requests until the list of interfaces is refreshed, which happens on routing changes or every 5 minutes by default. If the attack is repeated often enough (once per second), ntpd will not be able to synchronize with the source.
ntpd instances, and auto-restart ntpd (without -g) if it stops running.This weakness was discovered by Miroslav Lichvar of Red Hat.