From ${URL} : The busybox NTP implementation doesn't check the NTP mode of packets received on the server port and responds to any packet with the right size. This includes responses from another NTP server. An attacker can send a packet with a spoofed source address in order to create an infinite loop of responses between two busybox NTP servers. Adding more packets to the loop increases the traffic between the servers until one of them has a fully loaded CPU and/or network. It seems this bug was actually inherited from openntpd, on which the busybox implementation was based on. In openntpd it was fixed in: https://github.com/openntpd-portable/openntpd-openbsd/commit/28a2f904aafbf4c209fe6fa04ffb9308740fd78a Busybox upstream patch: https://git.busybox.net/busybox/commit/?id=150dc7a2b483b8338a3e185c478b4b23ee884e71 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
this is in the 1.25.1 release which should be fine for stable
@ Arches, please test and mark stable: =sys-apps/busybox-1.25.1
Stable on alpha.
amd64 stable
x86 stable
arm stable
sparc stable
ia64 stable
ppc stable
done the rest now
CVE-2016-6301 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-6301): The recv_and_process_client_pkt function in networking/ntpd.c in busybox allows remote attackers to cause a denial of service (CPU and bandwidth consumption) via a forged NTP packet, which triggers a communication loop.
This issue was resolved and addressed in GLSA 201701-05 at https://security.gentoo.org/glsa/201701-05 by GLSA coordinator Thomas Deutschmann (whissi).
*** Bug 621128 has been marked as a duplicate of this bug. ***
