bugbot adjusting priority

solution could be like this: https://bugzilla.redhat.com/show_bug.cgi?id=1047854#c3

Indeed. version 4.2.7 fixes this by removing monlist. Otherwise we
should restrict our default config. Are enterprise products affected?

No need to set needinfo to the bug assignee.

If everything before 4.2.7 is vulnerable, all enterprise products back to SLES9 are affected and all current openSUSE releases as well.

Shall I add the two lines (for IPv4 and IPv6) shown under "Disable status queries or restrict access" from http://www.kb.cert.org/vuls/id/348126 to our default config?

As this issue is not so severe, I am thinking if it
would be enough to fix it for Factory. If an admin really experiances
to be part of a DoS reflection attack, he can modify his config by himself.
It probably doesnt deserve an update to do so.

But for SLE12 and Factory, we should harden our config, yes.

I had a partner asking about this CVE and SLE.

Is the security team planning to write a support TID on this ?

If a TID is considered to be desirable or required, but the team is lacking resources, I can offer some assistance here.

*** Bug 859190 has been marked as a duplicate of this bug. ***

If they're talking about existing installations, an update won't help, because they've most probably edited /etc/ntp.conf and won't get replaced by the new one, so they'd still have to add the two lines mentioned in comment 5 manually.

But this is something the security team has to decide.

I agree with Sebastian, it's a simple configuration fix. So no security update planed. However I'm putting this on the planed update list.

A TID would be desirable.

The BSI is sending out abuse mails to root server owners in Germany and requesting to fix the issue (change of config file or close the port). It is actively used for attacks since Dec 2013.

https://www.cert-bund.de/advisoryshort/CB-K14-0020%20UPDATE%202

Reinhard, any suggestions on comment#10?

We could add in the description text that the particular
option should be disabled by hand if the congig was touched.

ok,I see, My customer has accepted it .

First abuse complaint in 12 years. — Yay! Not.

Also, ntp.conf(5) is terribly outdated and doesn't even mention the "restrict" option.

And yes, this IS a big thing, many of the sites I frequent are under DDoS attack for several months now. Please fix any of these amplification attack issues as soon as you become aware of it. Thanks.

Apparently BSI emailed a large amount of root server owners all throughout germany.

(In reply to comment #3)
> Indeed. version 4.2.7 fixes this by removing monlist.
According to http://support.ntp.org/bin/view/Main/SecurityNotice#DRDoS_Amplification_Attack_using this has been fixed with 4.2.7p27 on 2010-04-24, almost 4 years ago. Is there a reason to still use 4.2.6 instead of 4.2.7?

As I said before, a simple update with changed config file won't help, because it is packaged with %config(noreplace).

Descriptions that come with the update don't get displayed to people who do a simple "zypper up", which I guess covers many of the semipro root server owners.

Adding the fix to existing configurations in a %post script might be an option, but comes at a certain risk of breaking sophisticated setups for which the script wasn't prepared.

So, what shall we do?

(In reply to comment #21)
> Is there a reason to still use 4.2.6 instead of 4.2.7?

We don't usually ship development releases and 4.2.7 is still flagged as such.
See http://www.ntp.org/downloads.html .

But 4.2.6 seems to be unmaintained since 2011/12/24 and doesn't get security updates. Maybe you should ask the developers why they don't fix security bugs in their "stable" version.

I'd suggest tow things:

a) Update the defaults as soon as possible (for any new installation, 13.2 or whatever).

b) Security upgrade to 4.2.7 even if called development to fix the current monlist issue.

(In reply to comment #25)

> a) Update the defaults as soon as possible (for any new installation, 13.2 or
> whatever).

Agreed, and already being worked on.

> b) Security upgrade to 4.2.7 even if called development to fix the current
> monlist issue.

Given that 4.2.7 got about 15 patch releases over the last two months, I don't think this is an option, at least not for SLE.

http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/

See Bruce Schneier too:

https://www.schneier.com/blog/archives/2014/01/ddos_attacks_us.html

what is the needinfo for me...

(In reply to comment #27)

> what is the needinfo for me...

The question in comment 22 was meant for you as the head of the security team.

We will send out an advisory regarding the config change recommendation soon.

Upcoming products will feature the new hardened config already.

Why don't we touch all the old configuration files too?

We would add the CVE and bnc ID to the package change log and next release an update.  Customers would get the expected /etc/ntp.conf.rpmnew and would use the usual diff mechanism to notify the added option.  In the package change log they would find the reference to this bug.

And on top we would have the scheduled advisory regarding the required steps to harden a configuration.

(In reply to comment #30)
> Why don't we touch all the old configuration files too?

Because the ntp.conf (when used) is always modified. You can't replace it.

One solution would be an "fix this bug" postinstall update script (which hopefully does not destroy user configs - e.g. my already fixed ones which don't react to remote requests from unknown sources at all).

Dirk, Lars meant a solutiuon where the new config file would appear besides the system one.


Comment 30 would also be an option.

We could also use the %post edit mechanism that is used to add trusted keys
(available already in "ntp" in SLE11). 
Would anything speak against something like

grep restrict /etc/ntp.conf || echo  >> /etc/ntp.conf   <<EOF
# restrict stuff, comment out those lines if not wanted (see URL xyz
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
EOF  



Could we disable monlist in general, or also selectively enable it via config?

(In reply to comment #32)
> Dirk, Lars meant a solutiuon where the new config file would appear besides the
> system one.

Sorry, right. But does not help. Most people (i.e. these which still have an NTP issue) will ignore the new files. ;-)

> We could also use the %post edit mechanism that is used to add trusted keys
> (available already in "ntp" in SLE11). 
> Would anything speak against something like
> 
> grep restrict /etc/ntp.conf || echo  >> /etc/ntp.conf   <<EOF
> # restrict stuff, comment out those lines if not wanted (see URL xyz
> restrict default kod nomodify notrap nopeer noquery
> restrict -6 default kod nomodify notrap nopeer noquery
> EOF  

It kills most requests. You need to open localhost and ::1 also. And that is non-trivial for an existing config. Also you'd overwrite my config, which is "restrict default ignore" (together with individual allows).

NTP config is UGLY. An "only answer configured clients" option is missing.

> Could we disable monlist in general, or also selectively enable it via config?

Probably disabling monlist in installed config would be a solution as long as it does not kill better restrictions.

Probably adding .rpmnew and a "YOU SHOULD CHANGE YOU CONFIG" printed in the RPM install procedure is the best which can be done.

Yes, the way how Marcus described my approach is correct.  That's no solution of the problem at all.  But there would be an inactive ntp.conf.rpmnew file on any system where ntp.conf was modified before.

Such a /etc/ntp.conf.rpmnew file we even could reference in the announcement.  If you have none, all is fine.  If you have it it's up to you to merge these lines into your /etc/ntp.conf

A check like Marcus suggested with comment #32 I had in mind too.  But with the risk to block access to hosts of an internal, otherwise secured network.

(In reply to comment #33)
> Also you'd overwrite my config, which is
> "restrict default ignore" (together with individual allows).

Ah, overlooked the "grep". Maybe that really could work (together with opening the localhost(s).

This is an autogenerated message for OBS integration:
This bug (857195) was mentioned in
https://build.opensuse.org/request/show/214511 Factory / ntp

Think so, yes.

An update workflow for this issue was started.
This issue was rated as moderate.
Please submit fixed packages until 2014-07-28.
When done, reassign the bug to security-team@suse.de.
https://swamp.suse.de/webswamp/wf/58297

On review, we decided to still fix the templates that we ship to be not affected by the denial of service, to allow people installing fresh (and applying updates before configurtion) to be safe.

Reinhard, can you submit ntp for sle11 and opensuse 12.3,13.1?

Done.

*** Bug 889447 has been marked as a duplicate of this bug. ***

SUSE-SU-2014:0937-1: An update that solves one vulnerability and has one errata is now available.

Category: security (moderate)
Bug References: 838458,857195
CVE References: CVE-2013-5211
Sources used:
SUSE Linux Enterprise Server 11 SP3 for VMware (src):    ntp-4.2.4p8-1.24.1
SUSE Linux Enterprise Server 11 SP3 (src):    ntp-4.2.4p8-1.24.1
SUSE Linux Enterprise Desktop 11 SP3 (src):    ntp-4.2.4p8-1.24.1

fixed and released

openSUSE-SU-2014:0949-1: An update that fixes one vulnerability is now available.

Category: security (moderate)
Bug References: 857195
CVE References: CVE-2013-5211
Sources used:
openSUSE 13.1 (src):    ntp-4.2.6p5-15.5.1
openSUSE 12.3 (src):    ntp-4.2.6p5-9.6.1

At least on openSUSE 13.1 when configuring via YaST all default restrictions are removed from ntp.conf. So this patch has little practical value, unfortunately. TO make it effective YaST should be changed to set same policies by default.

Passing this on to YaST2.

The command "/etc/init.d/ntp status" calls ntpq (line 316). ntpq tries to contact the ntpd daemon on ::1, but the configuration only allows 127.0.0.1, not ::1, so eventually ntpq times out.

One fix would be to add "restrict ::1" to the configuration, but it would be better to remove the ntpq call from the stats action, especially since /etc/init.d/ntp calls itself for the status in some places where the output (and delay) is not wanted.

In general, when i ask for the status of a daemon, I want to know whether it is running or not, I don't want to wait for systemd to search the logs for messages related to the daemon. When I want the log messages, I will search for them myself, and then I know why I have to wait.

Reassigning to maintainer of yast2-ntp-client.

This is an autogenerated message for OBS integration:
This bug (857195) was mentioned in
https://build.opensuse.org/request/show/249398 Evergreen:11.4 / ntp

openSUSE-SU-2014:1149-1: An update that fixes one vulnerability is now available.

Category: security (moderate)
Bug References: 857195
CVE References: CVE-2013-5211
Sources used:
openSUSE 11.4 (src):    ntp-4.2.6p3-6.24.1

updates released