NTP

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

NTP

Theo de Raadt
The ntp daemon included in OpenBSD is our own openntpd, written
from scratch.

openntpd is not vulnerable.

Around 10 years ago it was written by Henning, at my request because
the ntpd source code scared the hell out of us.  At the time
communications with the ntp team showed they had little interest in
removing unused functionality from the ntp.org code, or any help with
our form of source code audit.

Because it was a rewrite, the major benefit in openntpd is that it
priviledge seperated.  If problems like these were found, they would
not be realistically exploitable.  Furthermore openntpd is a modern
piece of code <5000 lines long written using best known practices of
the time, whereas ntp.org's codebase is reportedly 100,000 lines of
unknown or largely unused code, poorly smithed in the past when these
kinds of programming mistakes were not a significant consideration.

This might be a good time to circle the conversation back to the
common practice of:

     srand(time(NULL));

Sorry, getting really jaded.  When will the software vendors WAKE THE
HELL UP?  This is not 2000 anymore.

It has become abundantly clear that it is very difficult to push
lessons regarding better software practices into the greater open
source community and the vendors who live off the teat.

enh
Reply | Threaded
Open this post in threaded view
|

Re: NTP

enh
on the bright side, clang's static analyzer encourages you to use
arc4random. from their unit tests:

  rand(); // expected-warning{{Function 'rand' is obsolete because it
implements a poor random number generator.  Use 'arc4random' instead}}
  drand48(); // expected-warning{{Function 'drand48' is obsolete
because it implements a poor random number generator.  Use
'arc4random' instead}}
  erand48(a); // expected-warning{{Function 'erand48' is obsolete
because it implements a poor random number generator.  Use
'arc4random' instead}}
  jrand48(a); // expected-warning{{Function 'jrand48' is obsolete
because it implements a poor random number generator.  Use
'arc4random' instead}}
  lcong48(a); // expected-warning{{Function 'lcong48' is obsolete
because it implements a poor random number generator.  Use
'arc4random' instead}}
  lrand48(); // expected-warning{{Function 'lrand48' is obsolete
because it implements a poor random number generator.  Use
'arc4random' instead}}
  mrand48(); // expected-warning{{Function 'mrand48' is obsolete
because it implements a poor random number generator.  Use
'arc4random' instead}}
  nrand48(a); // expected-warning{{Function 'nrand48' is obsolete
because it implements a poor random number generator.  Use
'arc4random' instead}}
  rand_r(&b); // expected-warning{{Function 'rand_r' is obsolete
because it implements a poor random number generator.  Use
'arc4random' instead}}
  random(); // expected-warning{{The 'random' function produces a
sequence of values that an adversary may be able to predict.  Use
'arc4random' instead}}

On Fri, Dec 19, 2014 at 5:22 PM, Theo de Raadt <[hidden email]> wrote:

> The ntp daemon included in OpenBSD is our own openntpd, written
> from scratch.
>
> openntpd is not vulnerable.
>
> Around 10 years ago it was written by Henning, at my request because
> the ntpd source code scared the hell out of us.  At the time
> communications with the ntp team showed they had little interest in
> removing unused functionality from the ntp.org code, or any help with
> our form of source code audit.
>
> Because it was a rewrite, the major benefit in openntpd is that it
> priviledge seperated.  If problems like these were found, they would
> not be realistically exploitable.  Furthermore openntpd is a modern
> piece of code <5000 lines long written using best known practices of
> the time, whereas ntp.org's codebase is reportedly 100,000 lines of
> unknown or largely unused code, poorly smithed in the past when these
> kinds of programming mistakes were not a significant consideration.
>
> This might be a good time to circle the conversation back to the
> common practice of:
>
>      srand(time(NULL));
>
> Sorry, getting really jaded.  When will the software vendors WAKE THE
> HELL UP?  This is not 2000 anymore.
>
> It has become abundantly clear that it is very difficult to push
> lessons regarding better software practices into the greater open
> source community and the vendors who live off the teat.
>



--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Java i18n/JNI/NIO, or bionic questions? Mail me/drop by/add me as a reviewer.

Reply | Threaded
Open this post in threaded view
|

Re: NTP

trondd
In reply to this post by Theo de Raadt
On Fri, Dec 19, 2014 at 8:22 PM, Theo de Raadt <[hidden email]>
wrote:

> whereas ntp.org's codebase is reportedly 100,000 lines of
> unknown or largely unused code
>

That made me curious.  Is it that bloated?

$ for i in $(find . -name "*.[ch]"); do cat $i >> allcode; done
$ egrep -v '[:blank:]*/?\*' allcode | grep -v "^ *$" | wc -l
  192870

This is ntp-4.2.8  A rough estimate but close enough if we are comparing to
a know solution that is <5000.

Keep up the good work.
Tim.
Reply | Threaded
Open this post in threaded view
|

Re: NTP

J Sisson
Using the same test on OpenNTPD from OpenBSD-STABLE:

# cd /usr/src/usr.sbin/ntpd/
# for i in $(find . -name "*.[ch]"); do cat $i >> /root/allcode; done
# egrep -v '[:blank:]*/?\*' /root/allcode | grep -v "^ *$" | wc -l
    2898

Quite a difference indeed.

On Fri, Dec 19, 2014 at 7:26 PM, trondd <[hidden email]> wrote:

> On Fri, Dec 19, 2014 at 8:22 PM, Theo de Raadt <[hidden email]>
> wrote:
>
>> whereas ntp.org's codebase is reportedly 100,000 lines of
>> unknown or largely unused code
>>
>
> That made me curious.  Is it that bloated?
>
> $ for i in $(find . -name "*.[ch]"); do cat $i >> allcode; done
> $ egrep -v '[:blank:]*/?\*' allcode | grep -v "^ *$" | wc -l
>   192870
>
> This is ntp-4.2.8  A rough estimate but close enough if we are comparing to
> a know solution that is <5000.
>
> Keep up the good work.
> Tim.



--
"BSD is what happens when Unix programmers port Unix to the x86.
Linux is what happens when x86 programmers write a Unix-like.
Windows is what happens when x86 programmers run all of their
programming textbooks through a blender, eat the ground up
remains of the text, and then code up what they can read in the
toilet 3 days later."

Reply | Threaded
Open this post in threaded view
|

Re: NTP

Theo de Raadt
In reply to this post by Theo de Raadt
> # cd /usr/src/usr.sbin/ntpd/
> # for i in $(find . -name "*.[ch]"); do cat $i >> /root/allcode; done
> # egrep -v '[:blank:]*/?\*' /root/allcode | grep -v "^ *$" | wc -l
>     2898
....
> > $ for i in $(find . -name "*.[ch]"); do cat $i >> allcode; done
> > $ egrep -v '[:blank:]*/?\*' allcode | grep -v "^ *$" | wc -l
> >   192870
> >
> > This is ntp-4.2.8  A rough estimate but close enough if we are comparing to
> > a know solution that is <5000.

That is a factor of 66x.  Shocking, it is larger than I remembered.

So, what does that extra source code bring to the table?

My perspective is that big code brings holes because fewer people want
to read, audit, and maintain the code.

But surely there must be some benefit.  It has been claimed NTPD is
more accurate.  For that extra size, is it 66x more accurate?  That's
silly.  Even if it is a little bit more accurate, what does 'more
accurate' mean when edge devices that care for more than ~100ms
accuracy are exceedingly rare?

The devices which care for accuracy are doing time distribution, not
time reception at the network edge.  And there lies the problem, I
think.  Much of that code is likely for special purposes in an
ecosystem which includes products, relationships with companies
building products, special modes, special features, labratory code,
etc.  The result was that this team built a NTP daemon for all
purposes great and small:

    One NTPD to rule them all,
    One NTPD to find them,
    One NTPD to bring them all
    and on the internet hole them

I am going to guess the serious time distribution people are in
control of this software stack, but 99% of their base is in the edge
devices where the extra complexity is unwarranted?  (Is it time for a
coup?)

I think the NTP people don't even know their own codebase because it
is too large and full of legacy code.  They don't know what parts of
it do, but they don't want to "upset their base" by removing any of
it.

In another project we recently reviewed, there was code all over the
place for some rotten platforms -- barely limping along -- but the
existance and structure of that code would would be cumbersome and the
effects would be detrimental to all platforms.  Developers trying to
change the code make mistakes -- or worse they get demoralized and
stop trying.  Such codebases purport to be about agility, but as it
tries to reach that goal which is increasingly less relevant, it hurts
the most important goals.  You cannot properly serve 1995 and 2015.

Back to NTPD, I suspect most of the people who struggled through it in
the last decade have been looking for holes to exploit.  It does not
seem healthy.  Healthy projects struggle with the effort of
refactoring their code.  Unhealthy project sit on their past results,
and the future catches up.

Certainly the codebase was also being run by strong-minded people,
I know the type.

The NTP codebase is larger than the SSH codebase.

Explain that, and then explain why noone visibly called them on that.


I recall the conversations I had with the NTP team bit around 10 years
ago.  They did not want help auditing their code.  It was sad, and I
found a more receptive audience in Henning.  Once he wrote openntpd,
we had to face public attacks from NTP team members.  Apparently the
openntpd math was bad and we would break internet time..  internet
still seems fine, except a ntp clients spun up to 100 peers is seeing
a fair number of ntp time distributions points are down...


I am glad to hear NTPD is being rewritten.  Because over time this
will bring safety back back into focus.  PHK, I hope you don't just
focus on the math.  Privsep it, please, but ensure DNS refresh is
possible in the architecture you choose.  There is a time-tested model
which does not require the OS to have this or that non-standard
security feature; we all know we can't mandate use of those features
which barely help anyways.  You rely on privsep everytime you login to
another machine, so consider it.



Very hard to push pressure upstream.

Reply | Threaded
Open this post in threaded view
|

Re: NTP

Hanno Böck
In reply to this post by Theo de Raadt
On Fri, 19 Dec 2014 18:22:47 -0700
Theo de Raadt <[hidden email]> wrote:

> openntpd is not vulnerable.

Depends on which vulnerability you mean.

It is probably vulnerable to this one:
http://zero-entropy.de/autokey_analysis.pdf
(tl;dr ntp authentication is not secure)

And it is probably vulnerable to this:
https://github.com/PentesterES/Delorean
(tl;dr Man-in-the-Middle)

ntp is not secure. openntpd is a more secure implementation of a
protocol that is not secure by design.

--
Hanno Böck
http://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NTP

Peter Hessler
On 2014 Dec 20 (Sat) at 12:42:52 +0100 (+0100), Hanno B??ck wrote:
:On Fri, 19 Dec 2014 18:22:47 -0700
:Theo de Raadt <[hidden email]> wrote:
:
:> openntpd is not vulnerable.
:
:Depends on which vulnerability you mean.
:
:It is probably vulnerable to this one:
:http://zero-entropy.de/autokey_analysis.pdf
:(tl;dr ntp authentication is not secure)
:

OpenNTPd does not do auth at all.


:And it is probably vulnerable to this:
:https://github.com/PentesterES/Delorean
:(tl;dr Man-in-the-Middle)
:

OpenNTPd embeds random cookies into several fields of the ntp packet,
the server is required to copy them back into the reply, and the client
checks them upon receiving it.

Not as vulnerable as you think.

:ntp is not secure. openntpd is a more secure implementation of a
:protocol that is not secure by design.
:
:--
:Hanno B??ck
:http://hboeck.de/
:
:mail/jabber: [hidden email]
:GPG: BBB51E42



--
If a President doesn't do it to his wife, he'll do it to his country.

Reply | Threaded
Open this post in threaded view
|

Re: NTP

Christian Weisgerber
On 2014-12-20, Peter Hessler <[hidden email]> wrote:

>:And it is probably vulnerable to this:
>:https://github.com/PentesterES/Delorean
>:(tl;dr Man-in-the-Middle)
>
> OpenNTPd embeds random cookies into several fields of the ntp packet,
> the server is required to copy them back into the reply, and the client
> checks them upon receiving it.
>
> Not as vulnerable as you think.

Perfectly vulnerable to MitM.  It just protects against random hosts
spraying you with bogus packets.

If you need authenticated NTP, use IPsec.  While there, you'll want
to authenticate nameserver replies, too.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NTP

John Long-4
In reply to this post by Theo de Raadt
On Fri, Dec 19, 2014 at 06:22:47PM -0700, Theo de Raadt wrote:
> The ntp daemon included in OpenBSD is our own openntpd, written
> from scratch.
>
> openntpd is not vulnerable.

Thank you OpenBSD people and project.

I just shitcanned ntp on my Linux box and replaced it with openntpd.
I plan to do the same on my Solaris boxes ASAP.

> It has become abundantly clear that it is very difficult to push
> lessons regarding better software practices into the greater open
> source community and the vendors who live off the teat.

I'm tired of this kind of attitude where people who should know better write
code that sort of works in some situations with all the options you never
need. There is much to be said for something well defined that solves a
problem and avoids others simply by paying attention and doing things right
instead of trying to support every possible feature at the expense of
safety and correctness.

Thank you for knowing better and doing better.

/jl

--
ASCII ribbon campaign ( ) Powered by Lemote Fuloong
 against HTML e-mail   X  Loongson MIPS and OpenBSD
   and proprietary    / \    http://www.mutt.org
     attachments     /   \  Code Blue or Go Home!
 Encrypted email preferred  PGP Key 2048R/DA65BC04