Re: [ntp:questions] What to do for clients less than 4.2.8?

[Gene Heskett]

On Tuesday 23 December 2014 00:47:14 William Unruh did opine
And Gene did reply:
> On 2014-12-23, Harlan Stenn  wrote:
> > Martin Burnicki writes:
> >> Rob wrote:
> >> > Martin Burnicki  wrote:
> >> >> And of course, the information flow was really bad here, so that
> >> >> it is very hard to figure out which systems are affected.
> >> > 
> >> > Indeed.  Only after 3 days there was a statement on the pool
> >> > mailing list that the problem only affected servers that can be
> >> > queried.  Well, that had better be stated in the original
> >> > release, so that 99.9% of the users of ntpd could immediately
> >> > move it to "not for me" and not be worried.
> >> 
> >> Yes. I agree that this information should have been available
> >> immediately with the first alert. This would have avoided much
> >> trouble.
> > 
> > And if we had realized all of this at first alert we would have.
> > 
> > The announcement came out 3 days' later than I wanted.  I'd been
> > working on this for 2 solid weeks by then.
> 
> Thank you very much.

I'll certainly second that. 3 days after it went public did seem like a 
very short time.  To all who have been working on it, many thanks.

And, the fix has made its way to the 10.04.4 LTS repo's already, so my 
build problem is solved.

And I could cut the traffic to the servers by 2/3rds if I could make this 
machine a server for my local network.  But thats a separate question I'll 
ask once the moderator clears my posts.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[brian utterback]

On 12/22/2014 11:05 PM, Harlan Stenn wrote:
> Martin Burnicki writes:
>> Rob wrote:
>>> Martin Burnicki  wrote:
 And of course, the information flow was really bad here, so that it is
 very hard to figure out which systems are affected.
>>> Indeed.  Only after 3 days there was a statement on the pool mailing list
>>> that the problem only affected servers that can be queried.  Well, that
>>> had better be stated in the original release, so that 99.9% of the users
>>> of ntpd could immediately move it to "not for me" and not be worried.
>> Yes. I agree that this information should have been available 
>> immediately with the first alert. This would have avoided much trouble.
> And if we had realized all of this at first alert we would have.
>
> The announcement came out 3 days' later than I wanted.  I'd been working
> on this for 2 solid weeks by then.

So, can we get a definitive statement, perhaps as an update to
http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/NEWS as to what an admin
can do to mitigate the problem until an update can be performed and
whether or not the same CVE's apply to xntpd?

-- 
Brian Utterback
Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:brian.utterb...@oracle.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Rob]

Harlan Stenn  wrote:
> Martin Burnicki writes:
>> Rob wrote:
>> > Martin Burnicki  wrote:
>> >> And of course, the information flow was really bad here, so that it is
>> >> very hard to figure out which systems are affected.
>> >
>> > Indeed.  Only after 3 days there was a statement on the pool mailing list
>> > that the problem only affected servers that can be queried.  Well, that
>> > had better be stated in the original release, so that 99.9% of the users
>> > of ntpd could immediately move it to "not for me" and not be worried.
>> 
>> Yes. I agree that this information should have been available 
>> immediately with the first alert. This would have avoided much trouble.
>
> And if we had realized all of this at first alert we would have.
>
> The announcement came out 3 days' later than I wanted.  I'd been working
> on this for 2 solid weeks by then.

Yes, I agree it would be very convenient when you had insight in programming
so you could work out things like that more efficiently.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[William Unruh]

On 2014-12-23, Harlan Stenn  wrote:
> Martin Burnicki writes:
>> Rob wrote:
>> > Martin Burnicki  wrote:
>> >> And of course, the information flow was really bad here, so that it is
>> >> very hard to figure out which systems are affected.
>> >
>> > Indeed.  Only after 3 days there was a statement on the pool mailing list
>> > that the problem only affected servers that can be queried.  Well, that
>> > had better be stated in the original release, so that 99.9% of the users
>> > of ntpd could immediately move it to "not for me" and not be worried.
>> 
>> Yes. I agree that this information should have been available 
>> immediately with the first alert. This would have avoided much trouble.
>
> And if we had realized all of this at first alert we would have.
>
> The announcement came out 3 days' later than I wanted.  I'd been working
> on this for 2 solid weeks by then.

Thank you very much. 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Harlan Stenn]

Martin Burnicki writes:
> Rob wrote:
> > Martin Burnicki  wrote:
> >> And of course, the information flow was really bad here, so that it is
> >> very hard to figure out which systems are affected.
> >
> > Indeed.  Only after 3 days there was a statement on the pool mailing list
> > that the problem only affected servers that can be queried.  Well, that
> > had better be stated in the original release, so that 99.9% of the users
> > of ntpd could immediately move it to "not for me" and not be worried.
> 
> Yes. I agree that this information should have been available 
> immediately with the first alert. This would have avoided much trouble.

And if we had realized all of this at first alert we would have.

The announcement came out 3 days' later than I wanted.  I'd been working
on this for 2 solid weeks by then.
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Rob]

Martin Burnicki  wrote:
>> I don't want DHCP to modify my NTP settings, or to restart ntpd.
>> (of course the neat thing about the above solution is that it is not
>> required to restart ntpd.  in Debian, for example, ntpd is restarted when
>> a DHCP lease with changed ntp option is received)
>
> For standard deployments on a huge number of clients the DHCP way very 
> much simplifies installation since you only have to configure the DHCP 
> server.
>
> On the other hand, it would be good if there was a simple (easy-to-find) 
> switch where you could disable such automatics.

Of course DHCP in itself is great, and I like it when devices (and maybe
workstations) automatically obtain the local timeserver address.
But what I DON'T like is when my carefully configured NTP server with
local refclock and configured secondary servers is turned into a client
of itself or another local system.

I agree that the enable/disable of this feature is often absent or very
hard to find.  Often you have to edit /etc/dhclient.conf or just
remove some script from /etc/dhclient.d but it is dangerous because
it may re-appear after a security update.
A simple "NTP_USE_DHCP=yes" that you can set to "no" when desired in
/etc/sysconfig/ntp or /etc/default/ntp would be so much better...

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Martin Burnicki]

Rob wrote:

Martin Burnicki  wrote:

And of course, the information flow was really bad here, so that it is
very hard to figure out which systems are affected.


Indeed.  Only after 3 days there was a statement on the pool mailing list
that the problem only affected servers that can be queried.  Well, that
had better be stated in the original release, so that 99.9% of the users
of ntpd could immediately move it to "not for me" and not be worried.


Yes. I agree that this information should have been available 
immediately with the first alert. This would have avoided much trouble.



So for now I presume it is on by default...  also because of what I saw
in the OpenSUSE example config.  (or would the "keys" config directive
be the magic enable crypto directive?)


Unfortunately openSUSE has (symmetric keys) crypto enabled to be able to
change ntpd's configuration at runtime via ntpq and/or ntpdc commands.
E.g. if the dhcp client receives a DHCP option with the IP of an an NTP
server it configures ntpd dynamically to use this server.


Ok, I always immediately cut out such behaviour after installing a system.


That's also what I do. I't interesting to see how the different ways to 
fiddle with the NTP configuration automatically evolve over time. ;-)



I don't want DHCP to modify my NTP settings, or to restart ntpd.
(of course the neat thing about the above solution is that it is not
required to restart ntpd.  in Debian, for example, ntpd is restarted when
a DHCP lease with changed ntp option is received)


For standard deployments on a huge number of clients the DHCP way very 
much simplifies installation since you only have to configure the DHCP 
server.


On the other hand, it would be good if there was a simple (easy-to-find) 
switch where you could disable such automatics.


Martin

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Paul]

On Mon, Dec 22, 2014 at 5:27 AM, David Woolley <
david@ex.djwhome.demon.invalid> wrote:

> On 22/12/14 04:02, Paul wrote:
>
>> And yet people apply critical monthly patches from Microsoft and Oracle
>> all
>> the time without running them through dev and q/a.
>>
>
> Not on business critical servers.
>

Normally I'd say we can agree to disagree but I can say with 100% certainty
that your statement is incorrect.

Some "businesses" have sufficient resources to manage zero-day exploints
and others don't.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Martin Burnicki]

Rob schrieb:

David Woolley  wrote:

On 21/12/14 10:48, Rob wrote:

People say "disable crypto" but there is no clear direction in the docs
on how to do that.  There is no "crypto off" or "disable crypto" config
directive at first glance.  So how is this done?


I would assume by not enabling it.


Ok, but in that case why the worry about the "millions of vulnerable
servers" on the internet, I think most users who just want to get and
serve time don't spend the week of time needed to get the crypto working
and to coordinate with other servers doing the same.


I think this is because they just didn't understand in which cases these 
vulnerabilities can be exploited.


And of course, the information flow was really bad here, so that it is 
very hard to figure out which systems are affected.



So for now I presume it is on by default...  also because of what I saw
in the OpenSUSE example config.  (or would the "keys" config directive
be the magic enable crypto directive?)


Unfortunately openSUSE has (symmetric keys) crypto enabled to be able to 
change ntpd's configuration at runtime via ntpq and/or ntpdc commands. 
E.g. if the dhcp client receives a DHCP option with the IP of an an NTP 
server it configures ntpd dynamically to use this server.


Martin

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Rob]

Martin Burnicki  wrote:
> Rob schrieb:
>> David Woolley  wrote:
>>> On 21/12/14 10:48, Rob wrote:
 People say "disable crypto" but there is no clear direction in the docs
 on how to do that.  There is no "crypto off" or "disable crypto" config
 directive at first glance.  So how is this done?
>>>
>>> I would assume by not enabling it.
>>
>> Ok, but in that case why the worry about the "millions of vulnerable
>> servers" on the internet, I think most users who just want to get and
>> serve time don't spend the week of time needed to get the crypto working
>> and to coordinate with other servers doing the same.
>
> I think this is because they just didn't understand in which cases these 
> vulnerabilities can be exploited.
>
> And of course, the information flow was really bad here, so that it is 
> very hard to figure out which systems are affected.

Indeed.  Only after 3 days there was a statement on the pool mailing list
that the problem only affected servers that can be queried.  Well, that
had better be stated in the original release, so that 99.9% of the users
of ntpd could immediately move it to "not for me" and not be worried.

>> So for now I presume it is on by default...  also because of what I saw
>> in the OpenSUSE example config.  (or would the "keys" config directive
>> be the magic enable crypto directive?)
>
> Unfortunately openSUSE has (symmetric keys) crypto enabled to be able to 
> change ntpd's configuration at runtime via ntpq and/or ntpdc commands. 
> E.g. if the dhcp client receives a DHCP option with the IP of an an NTP 
> server it configures ntpd dynamically to use this server.

Ok, I always immediately cut out such behaviour after installing a system.
I don't want DHCP to modify my NTP settings, or to restart ntpd.
(of course the neat thing about the above solution is that it is not
required to restart ntpd.  in Debian, for example, ntpd is restarted when
a DHCP lease with changed ntp option is received)

I was amazed to see that when updating ntpd from the OpenSUSE update,
the last part of ntp.conf which I commented-out was appended again by
the update script.  So I removed it again.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[David Woolley]

On 22/12/14 04:02, Paul wrote:

And yet people apply critical monthly patches from Microsoft and Oracle all
the time without running them through dev and q/a.


Not on business critical servers.  They may well apply them to general 
purpose desk top machines, but even then, if they don't have enough 
diversity, that can be a serious risk.


Also, what happens here is more akin to service pack, which is even more 
likely to get extensive lab testing.


I'm not sure if I've had a Microsoft update break anything in my 
non-critical system use, but I've certainly have had false positives 
from virus checker updates causing damage which wasted a hour or two on 
a  my home system, but if it had affected an important component on a 
critical server, or even on all the company workstations, it would be 
disastrous for the company.


Many businesses operate local repositories of Microsoft updates, not 
just to reduce bandwidth.


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[William Unruh]

In comp.protocols.time.ntp, you wrote:
> Bill,
>
> Are you willing to improve your deportment?
>
> You are performing an active dis-service.  I find your posts too often
> to be destructive, not constructive.  See below.
>
See below


> William Unruh writes:
>> On 2014-12-21, Jochen Bern  wrote:
>> > On 12/21/2014 12:38 PM, Rob wrote:
>> >> David Woolley  wrote:
>> >>> On 21/12/14 10:48, Rob wrote:
>>  People say "disable crypto" but there is no clear direction in the docs
>>  on how to do that.
>> >>>
>> >>> I would assume by not enabling it.
>> >> 
>> >> Ok, but in that case why the worry about the "millions of vulnerable
>> >> servers" on the internet, I think most users who just want to get and
>> >> serve time don't spend the week of time needed to get the crypto working
>> >> and to coordinate with other servers doing the same.
>> >
>> > According to what I read on
>> >
>> > http://support.ntp.org/bin/view/Main/SecurityNotice#Resolved_Vulnerabilitie
>> s
>> >
>> > -- CVE-2014-9293 *might* be exploitable on ntpd's that do *not* have
>> >explicit crypto settings in the config (but might be stopped by
>> >proper restrictions, it doesn't say),
>> > -- CVE-2014-9294 is irrelevant for non-crypto setups,
>> > -- *One third* of CVE-2014-9295 (the crypto_recv() part) requires an
>> >autokey setup, but the other two might not, and there's no statement
>> >of other requirements beyond basic reachability, and
>> > -- CVE-2014-9296 is *probably* unexploitable.
>> >
>> > As far as I'm concerned, 0.66 * -9295 is enough for me to grab the
>> > backports from the repos for our outward-serving ntpds right now ...
>> >J. Bern
>> 
>> There are lots of people who are strongly interested in having good
>> time, but cannot simply upgrade to 4.2.8. Many businesses have long
>> testing cycles to make sure a "fix" does not screw everything up
>> instead.
>
> There are times when quick action is needed and there are times when
> planning and discussion are needed.

?? And this was which?
This sure looked like quick action was needed, and there was, at
least to my eyes, insufficient information to base that action on. I took
down ntpd on the few ntpd machines running, but the importance of
accurate time on them was low. 

The fixes from ntpd came out fast, and that was great. Unforuntely the
diagnostics-- ie,  who exactly was vulnerable and what could be done to
make oneself less vulnerable (other than reinstalling which is
expensive) was less quick. 

>
> Successful (ie, those that survive) people and businesses know this.
>
> An active security vulnerability is not the right time for long testing
> cycles.  Indeed, I have previously stated that 4.2.7 has undergone a
> very long and thorough testing cycle.  One of the 6 patches has problems
> for some people, and one of the diagnostic updates for a pending patch
> had problems for some people.
>
>> Telling people how to protect their systems even if they cannot
>> immediately bring up 4.2.8 is crucial. The lack of informtion is a
>> severe disservice to the users. 
>
> The information on how to do that is in the security notice:
>
>  http://support.ntp.org/bin/view/Main/SecurityNotice

It was not there on Fri. (I looked) 
All I found were statements to upgrade. 

I am really glad it is there now. Thank you.


>
> See the section on "Resolved Vulnerabilities".
>
>> The exploits are out there already.
>
> Where?  I have see several reports like this but so far nobody has told
> me of any actual cases.  I'm not saying they are not there, I'm just
> saying nobody has told me about them.

I will admit that I do not have evidence of it. I do know that the
reports claim that it is. And that is what we have to go on. 



>
>> "My building is on fire, where are
>> the extinguishers" "We cannot tell you that because it might allow
>> firebugs to know how to set fires, just build a new building". "But my
>> building is on fire right now!"
>
> Yes, so follow the mitigation steps on the security release page, which
> lists some alternatives to an upgrade.

And previously we were told that more information should be withheld
because it might give people ideas of how to attack. that was what I was
responding to.

And it is not at all clear that those are alternatives to an upgrade. 



>
> Better still, let's get more *constructive* help going on.

And what would you find more constructive? Not mentioning concerns? NOt
criticising when I felt something was wrong? 

>
> H

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Paul]

On Sun, Dec 21, 2014 at 4:25 PM, William Unruh  wrote:

> There are lots of people who are strongly interested in having good
> time, but cannot simply upgrade to 4.2.8.
>

And yet people apply critical monthly patches from Microsoft and Oracle all
the time without running them through dev and q/a.

If time synchronization is business critical then it should be managed that
way.  For consumer operators there are trivial replacements. If you can't
figure out how to protect your infrastructure then you don't deserve much
(some but not much, Sony) sympathy.  This is simply not on the scale of
recent significant problems.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Harlan Stenn]

Bill,

Are you willing to improve your deportment?

You are performing an active dis-service.  I find your posts too often
to be destructive, not constructive.  See below.

William Unruh writes:
> On 2014-12-21, Jochen Bern  wrote:
> > On 12/21/2014 12:38 PM, Rob wrote:
> >> David Woolley  wrote:
> >>> On 21/12/14 10:48, Rob wrote:
>  People say "disable crypto" but there is no clear direction in the docs
>  on how to do that.
> >>>
> >>> I would assume by not enabling it.
> >> 
> >> Ok, but in that case why the worry about the "millions of vulnerable
> >> servers" on the internet, I think most users who just want to get and
> >> serve time don't spend the week of time needed to get the crypto working
> >> and to coordinate with other servers doing the same.
> >
> > According to what I read on
> >
> > http://support.ntp.org/bin/view/Main/SecurityNotice#Resolved_Vulnerabilitie
> s
> >
> > -- CVE-2014-9293 *might* be exploitable on ntpd's that do *not* have
> >explicit crypto settings in the config (but might be stopped by
> >proper restrictions, it doesn't say),
> > -- CVE-2014-9294 is irrelevant for non-crypto setups,
> > -- *One third* of CVE-2014-9295 (the crypto_recv() part) requires an
> >autokey setup, but the other two might not, and there's no statement
> >of other requirements beyond basic reachability, and
> > -- CVE-2014-9296 is *probably* unexploitable.
> >
> > As far as I'm concerned, 0.66 * -9295 is enough for me to grab the
> > backports from the repos for our outward-serving ntpds right now ...
> > J. Bern
> 
> There are lots of people who are strongly interested in having good
> time, but cannot simply upgrade to 4.2.8. Many businesses have long
> testing cycles to make sure a "fix" does not screw everything up
> instead.

There are times when quick action is needed and there are times when
planning and discussion are needed.

Successful (ie, those that survive) people and businesses know this.

An active security vulnerability is not the right time for long testing
cycles.  Indeed, I have previously stated that 4.2.7 has undergone a
very long and thorough testing cycle.  One of the 6 patches has problems
for some people, and one of the diagnostic updates for a pending patch
had problems for some people.

> Telling people how to protect their systems even if they cannot
> immediately bring up 4.2.8 is crucial. The lack of informtion is a
> severe disservice to the users. 

The information on how to do that is in the security notice:

 http://support.ntp.org/bin/view/Main/SecurityNotice

See the section on "Resolved Vulnerabilities".

> The exploits are out there already.

Where?  I have see several reports like this but so far nobody has told
me of any actual cases.  I'm not saying they are not there, I'm just
saying nobody has told me about them.

> "My building is on fire, where are
> the extinguishers" "We cannot tell you that because it might allow
> firebugs to know how to set fires, just build a new building". "But my
> building is on fire right now!"

Yes, so follow the mitigation steps on the security release page, which
lists some alternatives to an upgrade.

Better still, let's get more *constructive* help going on.

H

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[William Unruh]

On 2014-12-21, Jochen Bern  wrote:
> On 12/21/2014 12:38 PM, Rob wrote:
>> David Woolley  wrote:
>>> On 21/12/14 10:48, Rob wrote:
 People say "disable crypto" but there is no clear direction in the docs
 on how to do that.
>>>
>>> I would assume by not enabling it.
>> 
>> Ok, but in that case why the worry about the "millions of vulnerable
>> servers" on the internet, I think most users who just want to get and
>> serve time don't spend the week of time needed to get the crypto working
>> and to coordinate with other servers doing the same.
>
> According to what I read on
>
> http://support.ntp.org/bin/view/Main/SecurityNotice#Resolved_Vulnerabilities
>
> -- CVE-2014-9293 *might* be exploitable on ntpd's that do *not* have
>explicit crypto settings in the config (but might be stopped by
>proper restrictions, it doesn't say),
> -- CVE-2014-9294 is irrelevant for non-crypto setups,
> -- *One third* of CVE-2014-9295 (the crypto_recv() part) requires an
>autokey setup, but the other two might not, and there's no statement
>of other requirements beyond basic reachability, and
> -- CVE-2014-9296 is *probably* unexploitable.
>
> As far as I'm concerned, 0.66 * -9295 is enough for me to grab the
> backports from the repos for our outward-serving ntpds right now ...
>   J. Bern

There are lots of people who are strongly interested in having good
time, but cannot simply upgrade to 4.2.8. Many businesses have long
testing cycles to make sure a "fix" does not screw everything up
instead. Telling people how to protect their systems even if they cannot
immediately bring up 4.2.8 is crucial. The lack of informtion is a
severe disservice to the users. 
The exploits are out there already. "My building is on fire, where are
the extinguishers" "We cannot tell you that because it might allow
firebugs to know how to set fires, just build a new building". "But my
building is on fire right now!"

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Rob]

Jochen Bern  wrote:
> As far as I'm concerned, 0.66 * -9295 is enough for me to grab the
> backports from the repos for our outward-serving ntpds right now ...

Yes, for most systems I did the same, but I have the development version
of ntpd running on a couple of systems, and I have to either wait for
them to update the debian package on the ntp.org development server (which
may never happen) or to get and compile a raw tarball myself.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Jochen Bern]

On 12/21/2014 12:38 PM, Rob wrote:
> David Woolley  wrote:
>> On 21/12/14 10:48, Rob wrote:
>>> People say "disable crypto" but there is no clear direction in the docs
>>> on how to do that.
>>
>> I would assume by not enabling it.
> 
> Ok, but in that case why the worry about the "millions of vulnerable
> servers" on the internet, I think most users who just want to get and
> serve time don't spend the week of time needed to get the crypto working
> and to coordinate with other servers doing the same.

According to what I read on

http://support.ntp.org/bin/view/Main/SecurityNotice#Resolved_Vulnerabilities

-- CVE-2014-9293 *might* be exploitable on ntpd's that do *not* have
   explicit crypto settings in the config (but might be stopped by
   proper restrictions, it doesn't say),
-- CVE-2014-9294 is irrelevant for non-crypto setups,
-- *One third* of CVE-2014-9295 (the crypto_recv() part) requires an
   autokey setup, but the other two might not, and there's no statement
   of other requirements beyond basic reachability, and
-- CVE-2014-9296 is *probably* unexploitable.

As far as I'm concerned, 0.66 * -9295 is enough for me to grab the
backports from the repos for our outward-serving ntpds right now ...

Regards,
J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im :
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH 
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[David Woolley]

On 21/12/14 11:38, Rob wrote:

David Woolley  wrote:

On 21/12/14 10:48, Rob wrote:

People say "disable crypto" but there is no clear direction in the docs
on how to do that.  There is no "crypto off" or "disable crypto" config
directive at first glance.  So how is this done?


I would assume by not enabling it.


Ok, but in that case why the worry about the "millions of vulnerable
servers" on the internet, I think most users who just want to get and


Paranoia?  Security alerts are generally not that explicit (and this one 
is actually unusually explicit) because they provide information to the 
hackers.



serve time don't spend the week of time needed to get the crypto working
and to coordinate with other servers doing the same.

So for now I presume it is on by default...  also because of what I saw
in the OpenSUSE example config.  (or would the "keys" config directive
be the magic enable crypto directive?)


There are only two places where crypto_recv is called.  One is 
definitely only active if autokey has been explicitly configured.  The 
other is only active for broadcast clients and the comments imply that 
it is only used for autokey, but it does seem possible that it is the 
remote side that decides this (I didn't follow the code any deeper); it 
is in the initial broadcast client handshake.


I'm using 4.2.7p333, rather than the latest 4.2.7 source code.

"Carefully crafted" in alerts generally means that the data has to look 
like the address of some instructions and those instructions, with the 
exact memory layout under which that instance is running.  It also 
normally assumes that the machine doesn't have stack execution 
permission disabled for ntpd.




___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Rob]

David Woolley  wrote:
> Paranoia?  Security alerts are generally not that explicit (and this one 
> is actually unusually explicit) because they provide information to the 
> hackers.

That is usually obtained anyway be reverse-engineering the fix.
In this case that is more difficult because an entire new release was
pushed out as a fix.

> There are only two places where crypto_recv is called.  One is 
> definitely only active if autokey has been explicitly configured.  The 
> other is only active for broadcast clients and the comments imply that 
> it is only used for autokey, but it does seem possible that it is the 
> remote side that decides this (I didn't follow the code any deeper); it 
> is in the initial broadcast client handshake.

Ok that should make servers on internet less vulnerable.  Maybe an
attack can be done on a local network but I am not worried about that.

> I'm using 4.2.7p333, rather than the latest 4.2.7 source code.

Most interesting is of course the situation in 4.2.6p5
In 4.2.7 there are already changes that may have partly fixed this.

> "Carefully crafted" in alerts generally means that the data has to look 
> like the address of some instructions and those instructions, with the 
> exact memory layout under which that instance is running.  It also 
> normally assumes that the machine doesn't have stack execution 
> permission disabled for ntpd.

Of course I run ntpd as a dedicated user ntp and in a chroot.
That should also limit the impact.
This is default on OpenSUSE.  I think in Debian the separate user
is default but the chroot isn't.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[David Woolley]

On 21/12/14 10:48, Rob wrote:

People say "disable crypto" but there is no clear direction in the docs
on how to do that.  There is no "crypto off" or "disable crypto" config
directive at first glance.  So how is this done?


I would assume by not enabling it.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Rob]

David Woolley  wrote:
> On 21/12/14 10:48, Rob wrote:
>> People say "disable crypto" but there is no clear direction in the docs
>> on how to do that.  There is no "crypto off" or "disable crypto" config
>> directive at first glance.  So how is this done?
>
> I would assume by not enabling it.

Ok, but in that case why the worry about the "millions of vulnerable
servers" on the internet, I think most users who just want to get and
serve time don't spend the week of time needed to get the crypto working
and to coordinate with other servers doing the same.

So for now I presume it is on by default...  also because of what I saw
in the OpenSUSE example config.  (or would the "keys" config directive
be the magic enable crypto directive?)

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Rob]

David Woolley  wrote:
> On 20/12/14 22:01, Rob wrote:
>> David Woolley  wrote:
>>> On 20/12/14 19:58, William Unruh wrote:
 Is it an ntp packet (ie a time exchange packet)? is it a control packet
 (eg ntpq type packet?) or what?
 Ie, unless you use crypto, these two look like they might be dangerous.
>>>
>>> Both routines only process NTP type 6 packets, i.e. nptq.
>>
>> But is that before or after those packets are filtered by "restrict"?
>>
> ctl_putdata is sending the response (my guess is the attack is monlist 
> based), so it is definitely after the filter.  configure is a fairly 
> complex command processing option, so, although I didn't check the code 
> in detail, I would be most surprised if it wasn't after the filter.

Looking in the packet trace I see monlist attempts all the time, but
they are probably for the previous NTP issue.  I have restricted those,
but I feel unsure if I am vulnerable to the current problem.

People say "disable crypto" but there is no clear direction in the docs
on how to do that.  There is no "crypto off" or "disable crypto" config
directive at first glance.  So how is this done?

Again, the users are left in the dark.  There no default config file,
so all distributions make their own.  My OpenSUSE system includes:

#
# Authentication stuff
#
keys /etc/ntp.keys  # path for keys file
trustedkey 1# define trusted keys
requestkey 1# key (7) for accessing server variables
# controlkey 15 # key (6) for accessing server variables

I have commented those all.
But there is no such thing in the Debian config file.

Is crypto off by default?  I don't think so, because there is no crypto
statement in the OpenSUSE config file, yet it refers to crypto-related
settings.

How much simplere would it be when there was a news release telling us
what we need to config in our /etc/ntp.conf or what we need to trap in
the firewall.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[David Woolley]

On 20/12/14 22:01, Rob wrote:

David Woolley  wrote:

On 20/12/14 19:58, William Unruh wrote:

Is it an ntp packet (ie a time exchange packet)? is it a control packet
(eg ntpq type packet?) or what?
Ie, unless you use crypto, these two look like they might be dangerous.


Both routines only process NTP type 6 packets, i.e. nptq.


But is that before or after those packets are filtered by "restrict"?

ctl_putdata is sending the response (my guess is the attack is monlist 
based), so it is definitely after the filter.  configure is a fairly 
complex command processing option, so, although I didn't check the code 
in detail, I would be most surprised if it wasn't after the filter.


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[David Woolley]

On 20/12/14 20:54, A C wrote:

Ok, so the remaining uncertainty is whether some of the crafted packets
can be the response packets for a normal time exchange or if they're
only query/config packets.  The advisory isn't completely clear on what
types of packets can cause the buffer overflows.


ctl_putdata handles the responses to ntpq type control packets. 
configure is the action routine for a particular control type request. 
They are both in ntp_control.c, whose first four lines are:


/*
 * ntp_control.c - respond to mode 6 control messages and send async
 * traps.  Provides service to ntpq and others.
 */

I didn't check the encryption one, as casual users don't use encryption. 
 It may well turn out to be the encryption used for control packets.


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Rob]

David Woolley  wrote:
> On 20/12/14 19:58, William Unruh wrote:
>> Is it an ntp packet (ie a time exchange packet)? is it a control packet
>> (eg ntpq type packet?) or what?
>> Ie, unless you use crypto, these two look like they might be dangerous.
>
> Both routines only process NTP type 6 packets, i.e. nptq.

But is that before or after those packets are filtered by "restrict"?

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[David Woolley]

On 20/12/14 19:58, William Unruh wrote:

Is it an ntp packet (ie a time exchange packet)? is it a control packet
(eg ntpq type packet?) or what?
Ie, unless you use crypto, these two look like they might be dangerous.


Both routines only process NTP type 6 packets, i.e. nptq.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[A C]

On 2014-12-20 01:22, Martin Burnicki wrote:
> A C wrote:
>> I saw the advisory about the potential issues in ntpd before 4.2.8 but I
>> don't quite understand whether it affects a pure client (not serving
>> time to the outside) or not.
>>
>> If the issue does affect client-only operation, what can be done for
>> systems that can't be upgraded?
> 
> As far as I understand the reports on bugzilla the main vulnerabilities
> are in functions where signed packets (symmetric key or autokey) are
> received/checked, or dynamic/remote configuration via ntpq and/or ntpdc
> is enabled, which, as far as I know also requires some sort of crypto
> top be enabled.
> 
> So from my understanding disabling crypto in ntp.conf should avoid the
> main vulnerabilities as a first, quick step.
> 

Thanks Martin.  I already have crypto off so now it's a question of
whether a normal time poll packet can also be used against the server.
That's the part I'm not clear about.

Also thank you for getting the Windows version updated soon (seen in
your other email).  I currently have no way of compiling copies for Windows.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[A C]

On 2014-12-20 01:30, David Woolley wrote:
> On 20/12/14 09:22, Martin Burnicki wrote:
> 
>>
>> As far as I understand the reports on bugzilla the main vulnerabilities
>> are in functions where signed packets (symmetric key or autokey) are
>> received/checked, or dynamic/remote configuration via ntpq and/or ntpdc
>> is enabled, which, as far as I know also requires some sort of crypto
>> top be enabled.
>>
> 
> One might be in a pure status enquiry, so you may have to set noquery.
> 
> In any case, except possibly for people using encryption, and maybe not
> even them, these affect neither client nor server mode, only remote
> management.

Ok, so the remaining uncertainty is whether some of the crafted packets
can be the response packets for a normal time exchange or if they're
only query/config packets.  The advisory isn't completely clear on what
types of packets can cause the buffer overflows.

Right now my inbound firewall does not allow UDP port 123 so no outside
system can query my copies of ntpd (it will of course allow a response
packet for an internally initiated time query).  My concern is whether a
standard time packet reply from a remote system (a response to my local
ntpd polling) can cause these issues.


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[William Unruh]

On 2014-12-20, William Unruh  wrote:
> On 2014-12-20, David Woolley  wrote:
>> On 20/12/14 09:22, Martin Burnicki wrote:
>>
>>>
>>> As far as I understand the reports on bugzilla the main vulnerabilities
>>> are in functions where signed packets (symmetric key or autokey) are
>>> received/checked, or dynamic/remote configuration via ntpq and/or ntpdc
>>> is enabled, which, as far as I know also requires some sort of crypto
>>> top be enabled.
>>>
>>
>> One might be in a pure status enquiry, so you may have to set noquery.
>>
>> In any case, except possibly for people using encryption, and maybe not 
>> even them, these affect neither client nor server mode, only remote 
>> management.
>
> How can we, as users, protect ourselves against these bugs, assuming
> 4.2.8 is not installable at the present time. How would one set no
> crypto in the conf file? How can one disable remote management?
>
>>

The two bugs that might be dangerous are



* Buffer overflow in ctl_putdata()

  References: Sec 2668 / CVE-2014-9295 / VU#852879
  CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:P) Base Score: 7.5
  Versions: All NTP4 releases before 4.2.8
  Date Resolved: Stable (4.2.8) 18 Dec 2014

  Summary: A remote attacker can send a carefully crafted packet that
   can overflow a stack buffer and potentially allow malicious
   code to be executed with the privilege level of the ntpd process.

  Mitigation: Upgrade to 4.2.8, or later.

  Credit: This vulnerability was discovered by Stephen Roettger of the
   Google Security Team.

* Buffer overflow in configure()

  References: Sec 2669 / CVE-2014-9295 / VU#852879
  CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:P) Base Score: 7.5
  Versions: All NTP4 releases before 4.2.8
  Date Resolved: Stable (4.2.8) 18 Dec 2014

  Summary: A remote attacker can send a carefully crafted packet that
   can overflow a stack buffer and potentially allow malicious
   code to be executed with the privilege level of the ntpd process.

  Mitigation: Upgrade to 4.2.8, or later.

  Credit: This vulnerability was discovered by Stephen Roettger of the
   Google Security Team.




Both say "carefully crafted packet" but do not say what kind of packet.
Is it an ntp packet (ie a time exchange packet)? is it a control packet
(eg ntpq type packet?) or what?
Ie, unless you use crypto, these two look like they might be dangerous.

I find the lack of information disturbing.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[William Unruh]

On 2014-12-20, David Woolley  wrote:
> On 20/12/14 09:22, Martin Burnicki wrote:
>
>>
>> As far as I understand the reports on bugzilla the main vulnerabilities
>> are in functions where signed packets (symmetric key or autokey) are
>> received/checked, or dynamic/remote configuration via ntpq and/or ntpdc
>> is enabled, which, as far as I know also requires some sort of crypto
>> top be enabled.
>>
>
> One might be in a pure status enquiry, so you may have to set noquery.
>
> In any case, except possibly for people using encryption, and maybe not 
> even them, these affect neither client nor server mode, only remote 
> management.

How can we, as users, protect ourselves against these bugs, assuming
4.2.8 is not installable at the present time. How would one set no
crypto in the conf file? How can one disable remote management?

>

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[David Woolley]

On 20/12/14 09:22, Martin Burnicki wrote:



As far as I understand the reports on bugzilla the main vulnerabilities
are in functions where signed packets (symmetric key or autokey) are
received/checked, or dynamic/remote configuration via ntpq and/or ntpdc
is enabled, which, as far as I know also requires some sort of crypto
top be enabled.



One might be in a pure status enquiry, so you may have to set noquery.

In any case, except possibly for people using encryption, and maybe not 
even them, these affect neither client nor server mode, only remote 
management.


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Martin Burnicki]

A C wrote:

I saw the advisory about the potential issues in ntpd before 4.2.8 but I
don't quite understand whether it affects a pure client (not serving
time to the outside) or not.

If the issue does affect client-only operation, what can be done for
systems that can't be upgraded?


As far as I understand the reports on bugzilla the main vulnerabilities 
are in functions where signed packets (symmetric key or autokey) are 
received/checked, or dynamic/remote configuration via ntpq and/or ntpdc 
is enabled, which, as far as I know also requires some sort of crypto 
top be enabled.


So from my understanding disabling crypto in ntp.conf should avoid the 
main vulnerabilities as a first, quick step.


Martin

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] What to do for clients less than 4.2.8?

[Rob]

A C  wrote:
> I saw the advisory about the potential issues in ntpd before 4.2.8 but I
> don't quite understand whether it affects a pure client (not serving
> time to the outside) or not.
>
> If the issue does affect client-only operation, what can be done for
> systems that can't be upgraded?

Harlan has decided to keep us in the dark and feed us shit.

On the pool list someone asks what can be done to temporarily work around
the problem, and he does not even understand the question.  Is babbling
about needing money again, too.   Arghhh.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions