A vulnerability has been identified in TIM 3V-IE (incl. SIPLUS NET variants) (All versions < V2.8), TIM 3V-IE Advanced (incl. SIPLUS NET variants) (All versions < V2.8), TIM 3V-IE DNP3 (incl. SIPLUS NET variants) (All versions < V3.3), TIM 4R-IE (incl. SIPLUS NET variants) (All versions < V2.8), TIM 4R-IE DNP3 (incl. SIPLUS NET variants) (All versions < V3.3). The affected versions contain an open debug port that is available under certain specific conditions. The vulnerability is only available if the IP address is configured to 192.168.1.2. If available, the debug port could be exploited by an attacker with network access to the device. No user interaction is required to exploit this vulnerability. The vulnerability impacts confidentiality, integrity, and availability of the affected device. At the stage of publishing this security advisory no public exploitation is known.
ntpd in NTP 4.x before 4.2.8p8 allows remote attackers to cause a denial of service (ephemeral-association demobilization) by sending a spoofed crypto-NAK packet with incorrect authentication data at a certain time.
The processpacket function in ntpproto.c in ntpd in NTP 4.x before 4.2.8p8 allows remote attackers to cause a denial of service (peer-variable modification) by sending spoofed packets from many source IP addresses in a certain scenario, as demonstrated by triggering an incorrect leap indication.
NTP 4.x before 4.2.8p6 and 4.3.x before 4.3.90 do not verify peer associations of symmetric keys when authenticating packets, which might allow remote attackers to conduct impersonation attacks via an arbitrary trusted key, aka a "skeleton key."
It was found that NTP's decodenetnum() would abort with an assertion failure when processing a mode 6 or mode 7 packet containing an unusually long data value where a network address was expected. This could allow an authenticated attacker to crash ntpd.
External References:
https://github.com/ntp-project/ntp/blob/stable/NEWS#L295 http://support.ntp.org/bin/view/Main/SecurityNotice#October2015NTPSecurityVulner
A flaw was found in the way NTP handled rate limiting. An attacker able to send a large number of crafted requests to an NTP server could trigger the rate limiting on that server, and prevent clients from getting a usable reply from the server.
The default NTP configuration in Red Hat Enterprise Linux does not enable rate limiting.
External References:
https://www.cs.bu.edu/~goldbe/NTPattack.html
It was discovered that sntp program would hang in an infinite loop when a crafted NTP packet was received, related to the conversion of the precision value in the packet to double.