Upstream has issued an advisory in June:
This is a very minor issue. Basically, someone who has access from a remote machine to configure ntpd can also shut down (crash) ntpd. Remote configuration is also not enabled by default.
The RedHat bug for this is here:
Steps to Reproduce:
A few more minor security issues in ntp have been announced:
Fixes are linked in the message above.
ntp new security issue CVE-2015-5146 =>
ntp new security issue CVE-2015-5146, CVE-2015-519[4-6], CVE-2015-5219
Fedora has submitted an update for these issues to their QA:
Updated audit packages fix security vulnerability:
A flaw was found in the way ntpd processed certain remote configuration
packets. An attacker could use a specially crafted package to cause ntpd to
crash if the attacker had authenticated access to remote ntpd configuration
It was found that ntpd could crash due to an uninitialized variable when
processing malformed logconfig configuration commands, for example,
ntpq -c ":config logconfig a" (CVE-2015-5194).
It was found that ntpd exits with a segmentation fault when a statistics
type that was not enabled during compilation (e.g. timingstats) is
referenced by the statistics or filegen configuration command, for example,
ntpq -c ':config statistics timingstats'
ntpq -c ':config filegen timingstats' (CVE-2015-5195).
It was found that the :config command can be used to set the pidfile and
driftfile paths without any restrictions. A remote attacker could use
this flaw to overwrite a file on the file system with a file containing
the pid of the ntpd process (immediately) or the current estimated drift
of the system clock (in hourly intervals). For example,
ntpq -c ':config pidfile /tmp/ntp.pid'
ntpq -c ':config driftfile /tmp/ntp.drift' (CVE-2015-5196).
It was discovered that sntp 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 (CVE-2015-5219).
Updated packages in core/updates_testing:
MGA5TOO, MGA4TOO =>
Hi! I'm going to test this update on (in rough order):
All on VBox VMs.
Marking as MGA5-64-OK.
Marking as MGA4-32-OK .
MGA4TOO MGA5-64-OK =>
MGA4TOO MGA5-64-OK MGA4-32-OK
Marking as MGA5-32-OK .
MGA4TOO MGA5-64-OK MGA4-32-OK =>
MGA4TOO MGA5-64-OK MGA4-32-OK MGA5-32-OK
Marking as MGA4-64-OK. I think the update can be validated.
MGA4TOO MGA5-64-OK MGA4-32-OK MGA5-32-OK =>
MGA4TOO MGA5-64-OK MGA4-32-OK MGA5-32-OK MGA4-64-OK
(In reply to Shlomi Fish from comment #7)
> I think the update can be validated.
Then feel free to do it by added the validated_update keyword. It's not an issue if the advisory has not been uploaded yet, on the contrary it makes the need for it more visible on madb.
(In reply to Rémi Verschelde from comment #8)
> (In reply to Shlomi Fish from comment #7)
> > I think the update can be validated.
> Then feel free to do it by added the validated_update keyword. It's not an
> issue if the advisory has not been uploaded yet, on the contrary it makes
> the need for it more visible on madb.
Advisory uploaded. s/audit/ntp/
MGA4TOO MGA5-64-OK MGA4-32-OK MGA5-32-OK MGA4-64-OK =>
MGA4TOO advisory MGA5-64-OK MGA4-32-OK MGA5-32-OK MGA4-64-OK
An update for this issue has been pushed to Mageia Updates repository.
LWN reference for CVE-2015-5194 CVE-2015-5195 CVE-2015-5196 CVE-2015-5219:
CVE-2015-5196 is now known as CVE-2015-7703: