
Multiple vulnerabilities released in NTP - mahmoudimus
http://support.ntp.org/bin/view/Main/SecurityNotice#Buffer_overflow_in_ctl_putdata
======
dfc
PHK has been working on a rewrite of ntp sponsored by the Linux Foundation. He
has posted a couple of entries about his progress so far:
[http://phk.freebsd.dk/time/20140926.html](http://phk.freebsd.dk/time/20140926.html)

In the meantime Miroslav's chrony is a good alternative:
[http://chrony.tuxfamily.org/](http://chrony.tuxfamily.org/)

If you are looking for the fixed version you can grab 4.2.8 from
archive.ntp.org which is still responding to requests:
[http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.8.tar.gz](http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.8.tar.gz)

~~~
scrollaway
systemd also has a minimalistic ntp client. It does not implement the full ntp
spec but is sufficient for most desktop and server systems.

~~~
dfc
While the latter half of your comment is a matter of opinion/taste, the first
half is categorically incorrect. systemd-timesync _is not a minimalistic ntp
client,_ it is a minimalistic sntp client. But do not take my word for it, the
authors made this clear in the announcement:

    
    
      > A new "systemd-timesyncd" daemon has been added for synchronizing 
      > the system clock across the network. It implements an SNTP client.
    

I disagree that systemd-timesync is sufficient for most desktops and servers.
We do not even need to go down the rabbit hole of discussing one's required
stability/precision/accuracy to see a big problem with the "sufficiency" of
systemd for most desktops/servers and the developers acknowledge it a couple
sentences later in the announcement they "not bother with the full NTP
complexity, focusing on querying time from one remote server and synchronizing
the local clock to it." How do you detect falsetickers when you only have one
sample? When they decided to ignore all the complexity they also chose to
ignore clock drift. Maybe your dekstops/servers come with rubidium standards,
but the rest of us have crappy crystals. I like that ntp/chrony decided to
address clock drift...

------
Sarkie
[http://webcache.googleusercontent.com/search?q=cache%3Asuppo...](http://webcache.googleusercontent.com/search?q=cache%3Asupport.ntp.org%2Fbin%2Fview%2FMain%2FSecurityNotice%23Buffer_overflow_in_ctl_putdata&oq=cache%3Asupport.ntp.org%2Fbin%2Fview%2FMain%2FSecurityNotice%23Buffer_overflow_in_ctl_putdata&aqs=chrome..69i57j69i58.798j0j4&sourceid=chrome&es_sm=0&ie=UTF-8)

------
xorcist
It is important to know how NTP works before you set it up. Several of the
comments seem to be misguided. NTP is a peer-to-peer protocol, there are no
such thing as an "NTP server" or an "NTP client".

NTP measures clock drift over a server group. It discovers enough about your
topology to assign a statistical factor to each peer, so that a rogue or
broken server can not bring down the whole group.

Known good time (which is what the stratum value is, a measure of distance to
known good time) is then sprinkled in from several sources to drift the time
in the direction of true time.

Exactly as you should have a number of secondary DNS servers in different AS,
you should use several different time sources from different organizations. If
you are bigger than a closet shop, you might as well put your own GPS receiver
in there too when sparkfun sells them for $40, and enable authentication on
it.

~~~
ztnewman
You wouldn't consider a server at stratum 0 and NTP server?

~~~
xorcist
Dedicated ntp peers are often called servers. It's not strictly true in the
client/server protocol architecture sense.

------
PhantomGremlin
NTP is one of those old school Internet protocols that was developed in "a
more civilized age". The reference implementation "growed like Topsy" in an
academic setting. So it's not surprising that it has serious vulnerabilities.

Many years ago OpenBSD threw up their hands and just decided to roll their
own, named OpenNTPD. It's not nearly as full featured as the reference
implementation, but it works fine for most people.

Edit: forgot to mention that OpenNTPD does privilege separation (don't know if
reference implementation has added that yet). Which means that "executed with
the privilege level of the ntpd process" isn't nearly as scary as when the
process is running as root.

~~~
VonGuard
NTP's author, Eric Fair, is actually the son of the founder of Fair-Issac.
Very smart cat, but this was all written so, so long ago it was bound to be
exploitable sooner or later.

~~~
dfc
NTP's "author" \--where author is defined as author of the original RFC (958),
every subsequent RFC (1305, 5905, etc) and reference implementation-- is Prof.
David Mills. Prof. Mills is one of the unsung heros of the internet.

------
SCdF
Random non-trolling question by someone who is genuinely unfamiliar with the
problem space: is it worthwhile rewriting these utilities in a language that
avoids these sorts of problems? Is it because they're far more complicated
than I realise and rewrites would create more problems that it solves? It is
because until Rust is 1.0 there isn't a language that is suitable? Or am I
missunderstanding the problem completely?

My reasoning comes from the vast majority of problems I notice being from the
edge cases in managing memory, and so if I understand correctly there is a
whole suite of languages that mostly remove these problems.

~~~
lawnchair_larry
No, rewriting things in memory safe languages is absolutely something that
should be done where it makes sense. There is no good reason to write things
like ntpd in C anymore.

Anyone who says you'll just have a new set of similar issues is full of crap.
You'll likely have issues, but ruling out memory corruption out the door is an
indisputable win.

~~~
rian
Well, there are still some good reasons to write things in C. For one it's
standardized. Two it's ubiquitous.

I agree that projects should have a way to verify with 100% accuracy the
memory safety of their code. One way to do that is to rewrite in another
language.

Another way to do that is to use a static analyzer that lists out all unsafe
operations in your codebase. Here's one
[http://goto.ucsd.edu/csolve/](http://goto.ucsd.edu/csolve/). Adds an extra
build step / precommit-hook but IMO the cost/benefit is much better than
rewriting your project. After all, we can't just rewrite our code every time a
new safe language comes out.

~~~
lawnchair_larry
You don't seem to understand this problem space.

------
cheeseprocedure
Do these vulnerabilities impact a local ntpd instance responsible only for
local timekeeping? (In other words, does a compromised machine in pool.ntp.org
pose a threat?)

~~~
kevinday
There are 6 bugs that were announced.

#1 Weak default key in config_auth()

If you're only doing local timekeeping, and not using authentication (you'd
know if you were) this doesn't apply. Basically the automatically generated
key used for authentication (if you didn't specify one) was only 31 bits long
and easily guessable.

#2 non-cryptographic random number generator with weak seed used by ntp-keygen
to generate symmetric keys

Same as the above. If you're not using keyed sessions with remote hosts, this
doesn't apply to you. Even if you are, the worst you're losing here is that
someone could potentially mess with your clock.

#3 Buffer overflow in crypto_recv()

If you are using crypto (i.e. your ntp.conf file contains a line starting with
"crypto pw"), you are potentially remotely exploitable to remote code
execution. You probably do not have that configuration line set unless you
know you put it there.

#4 Buffer overflow in ctl_putdata()

From the sound of the post on ntp.org, this is the scary one. "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." This makes it sound like everyone is exploitable.
However, Redhat says "the ctl_putdata() flaw, by default, can only be
exploited via local attackers". This makes me believe if you have your
ntp.conf locked down using the 'restrict' lines you might not be vulnerable.

#5 Buffer overflow in configure()

This is the same as #4, ntp.org's advisory is vague enough that it sounds like
everyone is vulnerable. Redhat is saying "the configure() flaw requires
additional authentication to exploit." I do not know what this means.

#6 receive(): missing return on error

From their description, it's technically possible (but they haven't done it)
to get ntpd into a weird state that is unlikely to be exploitable.

TL;DR: You're possibly vulnerable to #4 and #5 on a stock configuration.
Redhat says no, ntp.org's advisory is vague enough that I'm not sure.

------
voidz
The ntpd daemon does not run as root. So, how is it able to change the time of
the system? Does it use setuid, or caps, or something else?

I wonder because this would also affect what arbitrary code could be run as
the ntp user.

~~~
yrro
It appears to use capabilities:

    
    
      $ ps u 561
      USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
      ntp        561  0.0  0.0   5856   780 ?        Ss   Jul14  22:37 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 103:107
    
      $ /sbin/getpcaps 561
      Capabilities for `561': = cap_net_bind_service,cap_sys_time+ep

------
hiphopyo
Might want to check out OpenBSD's OpenNTPD:

[http://www.openntpd.org/](http://www.openntpd.org/)

~~~
feld
I've talked to several developers about the state of NTP daemons and neither
OpenNTPD nor DragonflyBSD's dntpd are suitable replacements. Neither of those
support NTP Authentication nor do they have all of the required algorithms
required for proper timekeeping.

~~~
imanaccount247
>nor do they have all of the required algorithms required for proper
timekeeping.

I hear something like that a lot, yet all my systems run openntpd and all of
them are keeping proper time without issue. What exactly is so not proper
about it, and which algorithm exactly does it need to be "proper"?

~~~
wglb
From the openntpd.org site at
[http://www.openntpd.org/goals.html](http://www.openntpd.org/goals.html):

 _Reach a reasonable accuracy. We are not after the last microseconds._

Whereas NTP looks for maximum accuracy.

~~~
imanaccount247
There's a big difference between "proper" and "more accurate than
99.999999999% of people care about" though. How many microseconds of accuracy
do most people need? How many does openntpd provide and how many does the
other ntpd provide? Claiming it isn't "proper" because in theory it may be 2
microseconds less accurate in some circumstances sounds like FUD.

------
breadtk
The site appears to be non-responsive, here is a cached version of the page:
[https://webcache.googleusercontent.com/search?q=cache:jMcfip...](https://webcache.googleusercontent.com/search?q=cache:jMcfipOGXXwJ:support.ntp.org/bin/view/Main/SecurityNotice+&cd=1&hl=en&ct=clnk&gl=us)

------
PhantomGremlin
Theo de Raadt of OpenBSD weighs in on this issue:

[http://www.mail-archive.com/tech@openbsd.org/msg21729.html](http://www.mail-
archive.com/tech@openbsd.org/msg21729.html)

------
arca_vorago
This is interesting timing, I was just in the freenode #linux channel
yesterday asking about security issues with NTP. I got told it was a non-issue
and that I was "tilting at windmills". I have been using chronyd in Alpine
linux to good effect so far, but have really been wondering how bad it would
be if I just turned it all off.

~~~
kbar13
having a host clock that is out of sync can be incredibly troublesome,
especially if you have more than one system.

~~~
bbulkow
Especially if your distributed database relies on clocks, as some do.

~~~
kstrauser
Eww. What does that?

Vector clocks? Sure. UTC clocks? Not a chance in hell I'd ever trust them for
a reconciliation protocol. I've spent way too much time around the internals
of hypervisors, and seeing how various OSes (and versions of them) do and
don't keep time well in virtualized environments gives me zero confidence. The
fact that any two given cloud VMs agree on the time within 500ms is a
testament to the sheer bullheaded determination of their administrators.

Simply, you cannot trust timestamps between two machines to determine
ordering. If you do, you _will_ have a bad time sooner or later (so to speak).

~~~
grogers
AFAIK only spanner uses real time as a core primitive. They don't use ntp ;-)

Monotonic sequence numbers loosely based on real time are common, since you
can correlate the sequence number back to an actual time to look at logs, etc.
Time skew wouldn't break the protocol, just make it annoying to correlate
after the fact.

And of course any leasing system uses bounded clock skew rate between hosts,
but NOT bounded absolute skew.

------
AgentME
All of the buffer overflows are on the stack, right? Shouldn't the default
stack protector that most compilers today enable should stop that from being
exploitable for remote code execution?

I'm just trying to estimate the likelihood that anyone was hacked through this
vulnerability. Even with stack protection the vulnerability could be used to
crash ntp, so upgrading is a very good idea still.

~~~
rudolf0
There are ways of bypassing stack canaries, depending on the specific
application and environment. No exploitation mitigation is ever fool-proof.

Also, in many cases applications will be distributed or have Makefiles without
enabling stack canaries or sometimes even DEP and ASLR.

~~~
AgentME
>There are ways of bypassing stack canaries, depending on the specific
application and environment.

Bypassing a stack canary generally requires a separate memory disclosure
vulnerability if I remember right. (Or an interesting local variable in the
same function as the buffer like a function pointer, but I think compilers now
are smart enough to try to arrange buffers to be the last thing on the stack
before the canary.) It wouldn't be surprising if one existed, but I don't
think any were publicly disclosed now.

I guess what I'm asking is: 1) Are there any public exploits that get remote
code execution against NTP on modern systems (Should we expect that the
average MITM is popping shells with this already on most systems?), and 2) do
all modern distributions (like say Debian) containing NTP have the standard
default mitigations (DEP, stack canaries, etc) enabled on NTP, or why not?

------
hannob
The best solution is not to use ntp anyway. It's an unencrypted,
unauthenticated protocol vulnerable to Man in the Middle attacks. There was a
pretty neat attack presented at BH Europe circumventing HSTS with a MitM-
attack on NTP.

Better just replace it with tlsdate.

~~~
dfc
ntp network traffic can be authenticated with symetric keys or autokey
currently, and with NTS in the future. Many national labs support
authenticated time for free and even more provide authenticated ntp for a
fee.[1] Moreover if you care about time you can use a cheap GPS+PPS[2] as a
reference or splurge and get a CDMA card. Your "replace it with tlsdate"
solution makes little sense; at some point you need NTP or PTP to acquire and
synch to UTC.

Why would anyone need encrypted time synch? I do not understand the privacy
implications, UTC is not a secret.

[1]: For example: [http://www.nist.gov/pml/div688/grp40/auth-
ntp.cfm](http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm) or
[https://www.nrc-
cnrc.gc.ca/eng/solutions/advisory/calibratio...](https://www.nrc-
cnrc.gc.ca/eng/solutions/advisory/calibration/time_frequency.html#authenticated)

[2]: My sure gps puck cost $40. It works with the antenna sitting on the
window ledge inside my house.

~~~
FireBeyond
You need encrypted time sync when you don't have a local trusted source, and
to reduce your susceptibility to to pseudo MITM attacks (though, having just
said that, you're right - UTC isn't a secret, so an attacker could just use
that. However, and I'm not sure the answer, the key may be in how much
information is leaked to the NTP server on current clock drift state. That
being said, I'm fairly sure Kerberos etc don't require millisecond level time
sync...)

~~~
dfc
You are confusing authentication and encryption. Authenticated time protects
against MITM attacks. You can obtain authenticated time synch from many
national labs, such as NIST[1] or CRC[2].

I do not understand the need for confidentiality.

[1]: [http://www.nist.gov/pml/div688/grp40/auth-
ntp.cfm](http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm)

[2]: [https://www.nrc-
cnrc.gc.ca/eng/solutions/advisory/calibratio...](https://www.nrc-
cnrc.gc.ca/eng/solutions/advisory/calibration/time_frequency.html#authenticated)

~~~
FireBeyond
Well, my thought was that you might be able to determine local clock drift by
snooping. But as then mentioned, that's of near zero use, I suspect (as
anything that uses time sync for authentication or otherwise is not likely to
be that tightly bound to accuracy).

------
jbarham
Naturally DJB recognized and fixed the security problems of NTP, way back in
1998: [http://cr.yp.to/clockspeed.html](http://cr.yp.to/clockspeed.html)

 _Plus ça change, plus c 'est la même chose..._

------
ck2
_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._

Geez, in a time sync program? Nothing is safe anymore.

~~~
tedunangst
ntpd is a, uh, rather large time sync program.

~~~
jandrese
Indeed. PHK noted that it's on the order of 100,000 lines of code. That's a
staggering amount for something that queries a remote server and steers your
clock.

~~~
nknighthb
100,000 lines of C is certainly unnecessary for the most common usage of ntpd,
but it is far from staggering considering ntpd's full scope as a portable
client, server, and peer-to-peer node attempting high precision
synchronization on heterogeneous hardware across the globe.

It doesn't just "query a remote server and steer your clock", and "steer your
clock" is a lot more complicated than it sounds when you're trying to achieve
such precision.

~~~
phkamp
Actually, you're wrong.

Most of that source code is there for different and wrong reasons.

It doesn't take much source code to steer your clock precisly, we are talking
less than 100 lines.

What takes up space is all the "extras" and "nice to haves".

~~~
nknighthb
I don't think I am, and you haven't given me any reason to believe I am.

Why don't you list some of those "extras" and "nice to haves"? Some of them
are probably absolutely critical to my services. All of them are probably
critical to somebody's.

I don't think you're understanding that I'm not in any way disputing that we
need something orders of magnitude smaller for the most common case of a
simple desktop or server keeping an approximately accurate clock.

If your response to me talks about just steering a clock, _you are not
responding to me_.

~~~
phkamp
Apologies for being a bit terse, but I've got stuff to do, including buying
X-mas presents for my family :-)

I've already written about most of this in my little "time-blog" related to
this project:
[http://phk.freebsd.dk/time/index.html](http://phk.freebsd.dk/time/index.html)

Feel free to ask any questions not already answered there.

Right now ntimed is less than 4KLOC and while it isn't complete yet, it does
contain precision timekeeping, a data collector to record simulation input, a
simulator to chew on those tracefiles and the real-time clock-steering code.

It really isn't rocket size.

OpenBSD's NTP implementation is similar size, but they sort of threw their
hands op on smart clock-steering, opting instead for "KISS" from a security
point of view.

The main reason I didn't start from OpenBSD's NTP implementation is that it is
not aimed at being part of a larger family of time-keeping programs, like I
intend to deliver, so it wouldn't save me any time in the end.

(I'll be proud if OpenBSD adopts my ntimed, but I'll fully understand and
accept if they do not.)

Adding support for being a NTP server is mostly a matter of writing code to
defend against packet storms (See:
[http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#D-L...](http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#D-Link_and_Poul-
Henning_Kamp))

Adding refclocks should never happen in the "main" process, but rather they
should be separate processes, suitably sandboxed and interfaced via a good
simple API. (I have radical plans for this, which will allow refclocks to be
implemented in PL/1, REXX or INTERCAL if that's how you roll :-)

But right here, right now, my focus is to get the vast majority of all
machines away from running NTPD, purely as a matter of security and
robustness, while improving their timekeeping at the same time.

If ntimed-client ever grows above 10KLOC, I've failed that goal.

First preview release of the source code will happen this weekend.

~~~
nknighthb
You're defending a lot of stuff I didn't attack. Almost everything you're
doing sounds good to me, and I have no idea why you would think otherwise.

The only point I made was that 100,000 lines is not staggering for all of the
functionality ntpd encompasses, which goes way beyond just "query and steer".

I didn't say a typical NTP client should be 100,000 lines. 10,000 lines sounds
far, far too large to me, in fact, for the 80-90% case.

~~~
phkamp
First, all functionality included, NTPD is presently 363.000 lines of .c and
.h files.

Second, the 100.000 is my guesstimate of what is necessary for "core
functionality" and I think that is still a pretty staggering size for what
that "core functionality" is.

There is a lot of ancient infrastructure which complicates otherwise very
simple tasks, some design-choices, perfectly valid in 1980 should have been
revisited no later than 2000, far too much duplicated functionality, because
people didn't know or couldn't get the other copy working etc.

My initial plan was to do a serious rebuild of the existing code, in deference
to Prof. Dave Mills and NTPDs long legacy (probably one the longest running
open source projects!), but in the end I had to admit that such a strategy
would be inefficient on any relevant metric.

I think I could write a bare-bone NTP client in well less than 1000 lines, but
it wouldn't be very user-friendly, net-friendly or clock-friendly.

Usability in particular soaks up space, but we're not in 1980 any more, so
there is no excuse for stuff like this any more:

    
    
       #define  DEFPROPDELAY    0x00624dd3 /* 0.0015 seconds, 1.5 ms */
    

But doing this takes some code:

    
    
      critter phk> ./ntimed-client -p pll_std_capture_time
      Parameter:
            pll_std_capture_time
      Minimum:
            2.000e+01
      Maximum:
            1.000e+06
      Default:
            3.000e+02
      Description:
            Capture time before stiffning PLL.
    
            After this many seconds, the PLL will start to stiffen the P
            and I terms to gain noise immunity.  Decreasing risks that
            initial frequency capture is not finished, which will increase
            the offset-excursion.  Increasing just delays this stiffning.
    
      Failure: Stopping after parameter query.
    
    

I don't have a target size for the program, but 5-10.000 lines for a robust,
reliable, secure and usable time sync client sounds reasonable to me.

... and that will still be less than 3% of the current NTPD.

~~~
nknighthb
I really have no interest in this. You're being incredibly defensive and
looking for reasons to argue with someone you don't fundamentally disagree
with about trivial crap. For someone who professes to be so busy, that's very
strange.

~~~
talideon
I would guess that PHK, being PHK, is just being thorough rather than
defensive. After all, if you can avoid a lot of back and forth, you're saving
everybody time. Of all people here, he's definitely one of the ones worth
giving the benefit of the doubt.

------
tux
"The connection was reset" something weird going on. Lots of HN articles is
been removed by some one. Many sites I visited today, is just down.

------
kator
Do these apply to ntpd in OSX?

~~~
porsupah
I haven't verified the vulnerability locally, but as of OS X 10.10.1 (14B25),
ntpd at least identifies itself as version 4.2.6, which is affected.

------
adrr
Bad timing for such a vulnerability with the holidays and everything. I don't
have time for that.

------
SEJeff
Just give it a few weeks and I'm sure the systemd developers will make their
own "newer and better" ntpd.

~~~
WestCoastJustin
You're late to the party [https://wiki.archlinux.org/index.php/systemd-
timesyncd](https://wiki.archlinux.org/index.php/systemd-timesyncd) ;)

