Mark Sims said:

The Network Time Foundation (through Harlan Stenn’s hard work) has already released a patch synchronized with the publication of the referenced paper from Boston University:

http://nwtime.org/ntf-releases-ntp-security-patches-ntp-4-2-8p4/

Many of the comments on the Ars Technica piece are quite naive regarding timekeeping issues. This reflects an ongoing need for public education that Time-nuts as well as NTF can help supply.

Rob Seaman

Hi,

On 10/22/2015 07:54 AM, Rob Seaman wrote:

Vendors such as Meinberg has released updates too. Patch your systems.

We expected as much. I really wonder what took so long. Ah well.

Cheers,
Magnus

Am Wed, 21 Oct 2015 22:54:15 -0700
schrieb Rob Seaman seaman@noao.edu:

In my opinion, it would be interesting to know if other implementations
are affected as well.
Until now, I've come across the ntp mentioned above, maintained by
the network time foundation.
But there's also openntpd, maintained by the OpenBSD guys, and ntimed
by PHK, which IIRC both claim to address security. Likely there afre
even more out there...

But if I read that article on ars technica correctly, it looks like it
is something inherent to the ntp protocol itself and the definitions it
makes.

Poul-Henning, would you care to comment on that for ntimed?

Best regards,
Florian

Hi

Without the real paper(s) they are referencing, it’s impossible to evaluate what they
are saying. In order to actually address their points, it will have to be done on a paper
by paper basis.

Bob

On Sat, Oct 24, 2015 at 6:36 AM, Florian Teply usenet@teply.info wrote:

By the way, if you're running a public facing instance (client or server)
the patches in 4.2.8p4 and 4.3.76 are  incomplete and don't fix the worst
potential problem.  If you're concerned about the rate limiting attacks
the current best practice is to firewall and disable rate limiting.  There
are follow-up patches floating about if you want to attempt to resolve the
problem locally

In my opinion, it would be interesting to know if other implementations

Any implementation that does spoof-able rate limiting can be attacked.  I
don't see any mention of that in the OpenBSD conf file nor any mention in
the ntimed on github.

There are various programs that can exchange packets with an Network Time
Foundation (NTF) ntpd (ntimed, openntpd, chrony, sntp  etc. etc.) but that
don't implement the many many features in the NTF versions.  Perhaps
that's why none of those programs call themselves ntpd.

Interested parties can follow this on the ntp-pool and ntp-hackers lists.

Bob,

It was linked from the article. Some 18 pages of reading. Go and read
it. I will when I get the time... can somebody skew my time by skew my
NTP? Just read the article, it tells you how to pull it off.

Cheers,
Magnus

On 10/24/2015 03:02 PM, Bob Camp wrote:

Hi

…. and that paper references a whole raft of other papers. Until you dig down into each of them
it’s not at all apparent what is being referred to in some sections. In some cases they are going back
to things in the 1990’s. A lot has changed since then.

Bob

In message 20151024123614.7bbfe893@aluminium.mobile.teply.info, Florian Teply
writes:

Correct.

The article is basically about how you can change the time on a
computer you are attacking by spoofing NTP replies.

Apart from a little mitigation, all implementations will be vulnerable
to this, because that is what happens when you get your time from an
unauthenticated server somewhere on the net.

The only real cure is to have your own NTP servers.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Am Sun, 25 Oct 2015 07:14:24 +0000
schrieb "Poul-Henning Kamp" phk@phk.freebsd.dk:

Of course proper authentication would make this kind of attack more
difficult, but as far as I can see, I'd estimate the amount of
authenticated NTP traffic on the internet to be negligible. Symmetric
cryptography probably would fail due to configuration issues -
Essentially, one would need to obtain and configure the keys for every
single server, and the server admin would need to generate keys for
every single client, because a well-known server key is as secure as
using none at all. This would work for a setup of a limited number of
servers and clients, say between us time nuts, but definitely not for
serving the general public. And a proper public key authentication also
needs a way to sort of securely distributing public keys or
certificates or whatever is used today. Which for the general public
means running into the same hen-and-egg problem we already have for
all other sorts of communication in use today.

Which then of course must not rely on external sources for their time,
meaning at least one of them needs to be fed by a time source
independent of NTP. A simple PPS (that is, just the pulses) without
additional information on time-of-day probably would be as vulnerable
as native NTP and therefore wouldn't suffice. Feeding it the correct
time and date once should suffice though, as time is known to never
move backwards under normal circumstances.

Anyways, I guess for most time nuts this is a moot point as I'd expect
those to be somewhat independent of NTP as a time source.

Best regards,
Florian

Am Sun, 25 Oct 2015 13:34:43 +0000
schrieb Wojciech Owczarek wojciech@owczarek.co.uk:

Umm, well, I agree partially. Spoofed packets are unfortunately not
as rare as one might think.  Sure, in many cases they're easy to detect
and are dropped routinely by most ISPs. But once they're out in the
wild, they're virtually impossible to tell from legitimate packets. The
reference to "properly designed networks" excludes the case where one
depends on external servers of higher stratum than what is available
within the network under your control. A properly designed network
implies full control over it, which is hardly achievable once the public
internet enters the picture. As soon as two or more transit networks are
encountered - which isn't too uncommon and which usually are not under
your control - all odds are off.

If I'm not mistaken, the requirement is a bit more strict, as one would
need a reliable chain to stratum 1. Running your own stratum 1 server(s)
probably would be the preferred solution. But already a not too fancy
configuration of a lower stratum server makes the attack pretty
unlikely as one would need to spoof packets from the majority of
upstream servers. The parts that likely are least protected from this
kind of attacck isn't so much organizations but rather Joe Average, who
doesn't have the knowledge to mitigate things. And those mostly are not
the target of an attack of this kind.

I have a similar feeling, the reported attack vector has more of an
academic value than actually posing a real threat. Therefore the
attention it generated is a bit over the top. Having a working
authentication mechanism that also works for the general public I'd
still consider to be a desireable feature. Not so much because NTP is
unreliable, but because I feel that authentication is generally a must
nowadays. But that's just my personal opinion.

Best regards,
Florian

In message 20151025162731.7a4a7bd7@aluminium.mobile.teply.info, Florian Teply
writes:

That's because the standardized way of doing it doesn't really work.

Obviously.  There is no free lunch.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[This is my final contribution to this topic since real time-nuts using NTP
run their own S1 servers driven by their Thunderbolts (et.seq.) and don't
need to worry about this]

On Sun, Oct 25, 2015 at 11:27 AM, Florian Teply usenet@teply.info wrote:

Only loosely.  It might appear that RFC5095 admits certain attacks using
the 'debug' interface however the 'source'* document says (referring to the
'nonce' check)

"While it seems reasonable to expect this check to be performed on the KoD
packet as well, RFC 5905 [41, Sec. 7.4] does not seem to explicitly require
this."

I believe this is an incorrect interpretation but in any case I think it's
clear the RFC is ambiguous and the published "fix" is to explicitly
validate the nonce.  Other fixes include completely disabling the 'debug'
interface. Implicit in this is the need to update the NTPv4 RFC.

I advise those concerned to read RFC5095, the BU paper* (don't worry about
the 68 references) and check the NTP security notice** to draw your own
conclusions about this problem keeping in mind Wojciech's recent comments.

*http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf
**http://support.ntp.org/bin/view/Main/SecurityNotice

I would like to respond in a generic and sweeping way - having not read in
the detail Bob layed out for us required to fully analyze the situation -
to the notion that circuit level access or prior topological knowledge is
required to exploit this or any other spoofing attack.  On a corporation or
education network, I could generate such malformed packets with almost no
effort as long as i had my Mac or a similarly not-windows device, or access
to one.  I estimate it'd take less than 5 minutes for me to do for the
majority of targets - which means any motivated party could within an hour
or two. I'm not warranting I would succeed - hopefully there would be a
real firewall SOMEWHERE in the path from the open internet to a real
physical host.

IP routers are, by design, completely disinterested in source information
and the additional overhead of becoming aware and meaningfully acting on it
is significant - hence multimillion dollar price tags on single linecards
in most Internet-scale devices.  Additionally, the amount of knowledge
required to effectively benefit from it while avoiding massive
architectural issues is frequently impractical if not to distribute to the
necessary infrastructure devices.

Long story short: this sort of processing is only practical at the
very.ingress interfaces to a network.  In the case of a Level 3 sized
carrier that would mean the number of interfaces that are not protected
from such a packet would number literally in the millions.  Level 3 is a
poor example of an vulnerable path - i would be hard pressed to circumvent
their security strategies due to effective onion-like layering - but
AT&T's?  No problem.  All I need is one host that is willing to play and is
on a segment without reverse path forwarding  - which is all of them, in my
experience.  Once i am past the first hop I can get the rest of the way
there.

The network should not *ever be the solution *to a host vulnerability.  It
can provide a break-fix level of response but as I believe it was PHK said

• the only effective mitigation strategy starts with a real firewall
  followed by a very aggressively managed host.  The level of protection
  offered by standard anti-spoofing ACLs or advanced RPF detection is merely
  insurance.

Other effective strategies include NEVER allowing the internet to connect
directly to a host.  A simple reverse proxy or server load balancer
combined with a RFC 1918 numbering scheme on host networks is a VERY
powerful tool.  Such L4-7 inspection engines are just the ticket to foiling
an evil exploit.

NS

i Sun, Oct 25, 2015 at 2:01 PM Paul tic-toc@bodosom.net wrote:

Hi

Well here’s one of their points in “Attacking The Network Time Protocol":

They start off in the paper proposing the a KoD packet can be easily
used to disconnect NTP from it’s upstream time sources. Thus forging
KoD’s would appear to be the first step in their proposed attack.

Can you forge them - sure.

It would seem that things like polling rates are going to get into
the mix pretty fast. If I have an artificially high poling rate set up, it’s going
to be easier than if the rate has backed off to some slow rate. It also
will be easier to fake if I’m not doing some sort of burst (multi query)
check on the server(s).

So a question - how does all this impact your ability to do a faking prices?
Will you be flooding me with so many fake replies that a fairly simple patch
will spot what you are doing?

No, this isn’t the whole key to the whole thing. It’s just one of a big bundle of
things that need to be gone through.

Bob

In message CAK9pY-xZiTg0pL-bb0FzhyWqF_GjBEvbDwdM=W3LfPrgGwqruw@mail.gmail.com
, Neil Schroeder writes:

This is where it would really be helpful if people read the paper,
because they spend considerable text sorting through what requires
you to be in-band and what doesn't.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Neil Schroeder writes:

I invite you to take 5-15 minutes' time and find out.  I won't ask you
to (and I hope you don't) publish too much information on what you find
out, because that initial hurdle is "big enough" to keep the majority of
miscreants at bay.  However, give a tool to a script-kiddie...

But please do take a bit of time and try to implement this attack.

Once you are there, I'd appreciate any suggestions hou might have
regarding mitigation.

Harlan Stenn stenn@ntp.org
http://networktimefoundation.org - be a member!