Filtered by vendor Ntpsec Subscriptions
Filtered by product Ntpsec Subscriptions
Total 7 CVE
CVE Vendors Products Updated CVSS v3.1
CVE-2023-4012 1 Ntpsec 1 Ntpsec 2024-11-21 7.5 High
ntpd will crash if the server is not NTS-enabled (no certificate) and it receives an NTS-enabled client request (mode 3).
CVE-2021-22212 2 Fedoraproject, Ntpsec 2 Fedora, Ntpsec 2024-11-21 4 Medium
ntpkeygen can generate keys that ntpd fails to parse. NTPsec 1.2.0 allows ntpkeygen to generate keys with '#' characters. ntpd then either pads, shortens the key, or fails to load these keys entirely, depending on the key type and the placement of the '#'. This results in the administrator not being able to use the keys as expected or the keys are shorter than expected and easier to brute-force, possibly resulting in MITM attacks between ntp clients and ntp servers. For short AES128 keys, ntpd generates a warning that it is padding them.
CVE-2019-6445 1 Ntpsec 1 Ntpsec 2024-11-21 N/A
An issue was discovered in NTPsec before 1.1.3. An authenticated attacker can cause a NULL pointer dereference and ntpd crash in ntp_control.c, related to ctl_getitem.
CVE-2019-6444 1 Ntpsec 1 Ntpsec 2024-11-21 N/A
An issue was discovered in NTPsec before 1.1.3. process_control() in ntp_control.c has a stack-based buffer over-read because attacker-controlled data is dereferenced by ntohl() in ntpd.
CVE-2019-6443 1 Ntpsec 1 Ntpsec 2024-11-21 N/A
An issue was discovered in NTPsec before 1.1.3. Because of a bug in ctl_getitem, there is a stack-based buffer over-read in read_sysvars in ntp_control.c in ntpd.
CVE-2019-6442 1 Ntpsec 1 Ntpsec 2024-11-21 N/A
An issue was discovered in NTPsec before 1.1.3. An authenticated attacker can write one byte out of bounds in ntpd via a malformed config request, related to config_remotely in ntp_config.c, yyparse in ntp_parser.tab.c, and yyerror in ntp_parser.y.
CVE-2016-1551 2 Ntp, Ntpsec 2 Ntp, Ntpsec 2024-11-21 N/A
ntpd in NTP 4.2.8p3 and NTPsec a5fb34b9cc89b92a8fef2f459004865c93bb7f92 relies on the underlying operating system to protect it from requests that impersonate reference clocks. Because reference clocks are treated like other peers and stored in the same structure, any packet with a source ip address of a reference clock (127.127.1.1 for example) that reaches the receive() function will match that reference clock's peer record and will be treated as a trusted peer. Any system that lacks the typical martian packet filtering which would block these packets is in danger of having its time controlled by an attacker.