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 figur
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
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 mai
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
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 proble
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)
>
> F
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. W
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
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.
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
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 enou
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 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.
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 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 c
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
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 vuln
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
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 ent
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.
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,
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
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 proces
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
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,
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.
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
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 ntp
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,
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/
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
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
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?
Ha
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?
__
34 matches
Mail list logo
