Debian Bug report logs - #687166
ntp: NTP security vulnerability because not using authentication by default

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: none <anotst01@fastmail.fm>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: ntp: NTP security vulnerability because not using authentication by default

Date: Mon, 10 Sep 2012 13:35:29 +0000

Package: ntp
Version: 1:4.2.6.p3+dfsg-1ubuntu3.1
Severity: normal
Tags: security

Debian implements so much security one way or another. So much defenses against
network level man in the middle or malicious proxies or wifi hotspots.
Cryptographic verification generally works well but there is one big drawback:
it requires correct date/time.

NTP in Debian does not use any authentication by default, although it is
supported by NTP.

I conclude, that almost no one is using authenticated NTP, because there are no
instructions in a forum or blog how to enable NTP authentication. Therefore
almost everyone uses standard configuration and is at risk.

An adversary can tamper with the unauthenticated NTP replies and put the users
time several years back, especially, but not limited, if the bios battery or
hardware clock is defect. That issue becomes more relevant with new devices
like RP, which do not even have a hardware clock.

Putting the clock several years back allows an adversary to use already
revoked, broken, expired certificates; replay old, broken, outdated, known
vulnerable updates etc.

Suggested solutions:
- NTP supports public and private keys:
  http://doc.ntp.org/4.1.0/genkeys.htm
  Use it.
- Write easy documentation how to host an authenticated NTP server.
- Write easy documentation how to use an authenticated NTP server.
- Add gui optoins for using authenticated NTP.
- Debian could run their own authenticated NTP server.
- Debian has importance. You could officially ask the NTP pool if they could
add authentication.
- Debian could publicly the problem and ask the community for help.
- I am sure some NTP server volunteers would like to add authentication, if you
can provide clear instructions for them.

Message #10 received at 687166@bugs.debian.org (full text, mbox, reply):

From: Nico Golde <nion@debian.org>

To: none <anotst01@fastmail.fm>, 687166@bugs.debian.org

Cc: ask@develooper.com

Subject: Re: Bug#687166: ntp: NTP security vulnerability because not using authentication by default

Date: Mon, 10 Sep 2012 17:13:36 +0200

[Message part 1 (text/plain, inline)]

Hi,
* none <anotst01@fastmail.fm> [2012-09-10 15:42]:
[...] 
> An adversary can tamper with the unauthenticated NTP replies and put the users
> time several years back, especially, but not limited, if the bios battery or
> hardware clock is defect. That issue becomes more relevant with new devices
> like RP, which do not even have a hardware clock.
> 
> Putting the clock several years back allows an adversary to use already
> revoked, broken, expired certificates; replay old, broken, outdated, known
> vulnerable updates etc.

NTP is certainly subject to spoofing attacks by its nature. I also agree that 
this may be a problem in some settings. Just considering that e.g. kerberos is 
making heavy use of accurate timing. In theory NTP should be robust against 
wrong timing information from single servers. Obviously this doesn't help you, 
if your DNS is also spoofed and you control all NTP servers.

Since NTP does support symmetric/autokey by now, what I really wonder about is
why this is no strict requirement for servers in pool.ntp.org to which 
certainly also our debian ntp vendor zone belongs.

I think it would be desirable to ship default configurations with those keys 
setup.

I CC'ed Ask who is maintaining pool.ntp.org for this discussion.
Ask, is there such a requirement and I missed it or is it not existent?
If not, how realistic is it to change this?

While I don't think this is a critical problem, I'd also love to see this 
changed in future default configurations of the ntp package in Debian.

Kind regards
Nico
-- 
Nico Golde - http://www.ngolde.de - nion@jabber.ccc.de - GPG: 0xA0A0AAAA

[Message part 2 (application/pgp-signature, inline)]

Message #15 received at 687166@bugs.debian.org (full text, mbox, reply):

From: Ask Bjørn Hansen <ask@ntppool.org>

To: Nico Golde <nion@debian.org>

Cc: none <anotst01@fastmail.fm>, 687166@bugs.debian.org

Subject: Re: Bug#687166: ntp: NTP security vulnerability because not using authentication by default

Date: Mon, 10 Sep 2012 09:01:44 -0700

On Sep 10, 2012, at 8:13, Nico Golde <nion@debian.org> wrote:

Hi,

[Adding NTP authentication]

> I CC'ed Ask who is maintaining pool.ntp.org for this discussion.
> Ask, is there such a requirement and I missed it or is it not existent?
> If not, how realistic is it to change this?

Completely unrealistic with volunteer/public servers, sadly.   If you give it a bit of thought you'll realize it can't work. :-)

If we were to add authentication to the pool.ntp.org system, everyone would have to know the key so it'd not serve any purpose at all.

We could setup a set of servers with authentication, but that'd be a much smaller list of servers (for better and worse). It wouldn't be like the current NTP Pool at all.

Next would be to add DNSSEC to the DNS (which is non-trivial with the current zone and the current resources; at peaks the DNS servers get 20-30k qps and each response is different so you have to sign in "real-time".).

If there's a need and resources, I could run a zone with DNSSEC and with autokey configured, but it'd not be possible in the "open source"/"everyone volunteers a resource or two" scheme.


Ask

Message #20 received at 687166@bugs.debian.org (full text, mbox, reply):

From: Nico Golde <nion@debian.org>

To: Ask Bjørn Hansen <ask@ntppool.org>

Cc: none <anotst01@fastmail.fm>, 687166@bugs.debian.org

Subject: Re: Bug#687166: ntp: NTP security vulnerability because not using authentication by default

Date: Mon, 10 Sep 2012 18:18:42 +0200

[Message part 1 (text/plain, inline)]

Hi,
* Ask Bjørn Hansen <ask@ntppool.org> [2012-09-10 18:03]:
> On Sep 10, 2012, at 8:13, Nico Golde <nion@debian.org> wrote:
> [Adding NTP authentication]
>
> We could setup a set of servers with authentication, but that'd be a much 
> smaller list of servers (for better and worse). It wouldn't be like the 
> current NTP Pool at all.
> 
> Next would be to add DNSSEC to the DNS (which is non-trivial with the 
> current zone and the current resources; at peaks the DNS servers get 20-30k 
> qps and each response is different so you have to sign in "real-time".).
> 
> If there's a need and resources, I could run a zone with DNSSEC and with 
> autokey configured, but it'd not be possible in the "open source"/"everyone 
> volunteers a resource or two" scheme.

Wouldn't it still make sense to have a zone configured with autokey even 
without DNSSEC? Or is an active attacker bombarding the victim with faked NTP 
responses without spoofed DNS not an issue at all, so all this matters *only* 
if DNS is spoofed?

Kind regards
Nico
P.S: I'm all but an NTP expert :)
-- 
Nico Golde - http://www.ngolde.de - nion@jabber.ccc.de - GPG: 0xA0A0AAAA

[Message part 2 (application/pgp-signature, inline)]

Message #25 received at 687166@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Nico Golde <nion@debian.org>, 687166@bugs.debian.org

Cc: Ask Bjørn Hansen <ask@ntppool.org>, none <anotst01@fastmail.fm>

Subject: Re: [pkg-ntp-maintainers] Bug#687166: ntp: NTP security vulnerability because not using authentication by default

Date: Mon, 10 Sep 2012 18:51:57 +0200

On Mon, Sep 10, 2012 at 06:18:42PM +0200, Nico Golde wrote:
> Hi,
> * Ask Bjørn Hansen <ask@ntppool.org> [2012-09-10 18:03]:
> > On Sep 10, 2012, at 8:13, Nico Golde <nion@debian.org> wrote:
> > [Adding NTP authentication]
> >
> > We could setup a set of servers with authentication, but that'd be a much 
> > smaller list of servers (for better and worse). It wouldn't be like the 
> > current NTP Pool at all.
> > 
> > Next would be to add DNSSEC to the DNS (which is non-trivial with the 
> > current zone and the current resources; at peaks the DNS servers get 20-30k 
> > qps and each response is different so you have to sign in "real-time".).
> > 
> > If there's a need and resources, I could run a zone with DNSSEC and with 
> > autokey configured, but it'd not be possible in the "open source"/"everyone 
> > volunteers a resource or two" scheme.
> 
> Wouldn't it still make sense to have a zone configured with autokey even 
> without DNSSEC? Or is an active attacker bombarding the victim with faked NTP 
> responses without spoofed DNS not an issue at all, so all this matters *only* 
> if DNS is spoofed?

Autokey does several things, the most important of those is to
authenticate the peer your're talking too.

I don't see DNSSEC adding anything useful if autokey is used,
unless we also want to distribute the public keys via DNS.


Kurt

Message #30 received at 687166@bugs.debian.org (full text, mbox, reply):

From: Ask Bjørn Hansen <ask@ntppool.org>

To: Kurt Roeckx <kurt@roeckx.be>

Cc: Nico Golde <nion@debian.org>, 687166@bugs.debian.org, none <anotst01@fastmail.fm>

Subject: Re: [pkg-ntp-maintainers] Bug#687166: ntp: NTP security vulnerability because not using authentication by default

Date: Mon, 10 Sep 2012 14:06:52 -0700

Hi Kurt,

Of course you are right. DNSSEC will help a different use case.

That leaves us the first problem of the keys having to be secret which is impossible if "random servers" are hosting them.

If the Debian project had a set of servers with autokey configured that should be used for ntp.debian.org or auth.debian.pool.ntp.org or some such then we could setup the NTP Pool system to do the monitoring and DNS for those.


Ask

Message #35 received at 687166@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Ask Bjørn Hansen <ask@ntppool.org>

Cc: Nico Golde <nion@debian.org>, 687166@bugs.debian.org, none <anotst01@fastmail.fm>

Subject: Re: [pkg-ntp-maintainers] Bug#687166: ntp: NTP security vulnerability because not using authentication by default

Date: Tue, 11 Sep 2012 00:07:57 +0200

On Mon, Sep 10, 2012 at 02:06:52PM -0700, Ask Bjørn Hansen wrote:
> Hi Kurt,
> 
> Of course you are right. DNSSEC will help a different use case.
> 
> That leaves us the first problem of the keys having to be secret which is impossible if "random servers" are hosting them.
> 
> If the Debian project had a set of servers with autokey configured that should be used for ntp.debian.org or auth.debian.pool.ntp.org or some such then we could setup the NTP Pool system to do the monitoring and DNS for those.

I'm not sure Debian wants to run ntp.debian.org.  We would need to
ask people to donate resources for that, and the pool project
already exists for that.

We do internally run autokey between *.debian.org hosts, but that's not
for other people to query.

I don't really understand autokey.  But from reading things
I understand there are 4 authentication scheme's and 5
identity schemes and it works in groups, and clients would
need to have secret keys that belong to the same group.

So my understanding of things is that even if we also had
a way to distribute all the public keys, you still can't
get it to work as you need to provide each client with
a secret key.

I think what first needs to be done is have an autokey
implementation that either doesn't need a private key for
each client but is secure or doesn't need state on the
server side for each client.

If you want to drop state for each client in the server,
I think that's going to require the client to send it's
public key for each query.

In any case, I think this is going to significatly
increase bandwidth and cpu usage on the servers.


Kurt

Message #40 received at 687166@bugs.debian.org (full text, mbox, reply):

From: Ask Bjørn Hansen <ask@ntppool.org>

To: Kurt Roeckx <kurt@roeckx.be>

Cc: Nico Golde <nion@debian.org>, 687166@bugs.debian.org, none <anotst01@fastmail.fm>

Subject: Re: [pkg-ntp-maintainers] Bug#687166: ntp: NTP security vulnerability because not using authentication by default

Date: Mon, 10 Sep 2012 15:57:54 -0700

On Sep 10, 2012, at 15:07, Kurt Roeckx <kurt@roeckx.be> wrote:

> I'm not sure Debian wants to run ntp.debian.org.  We would need to
> ask people to donate resources for that, and the pool project
> already exists for that.

Indeed!  Sorry I wasn't clear.  The NTP Pool system can work on other domains than pool.ntp.org, so with a few NS pointers *.ntp.debian.org could be the NTP Pool but only including hosts configured and monitored "to the debian specifications" (including autokey etc as appropriate).

Then the pool system can still do the monitoring, automatically update DNS, point clients to "nearby" servers, etc.

[...]
> So my understanding of things is that even if we also had
> a way to distribute all the public keys, you still can't
> get it to work as you need to provide each client with
> a secret key.
> 
> I think what first needs to be done is have an autokey
> implementation that either doesn't need a private key for
> each client but is secure or doesn't need state on the
> server side for each client.

Indeed; I thought ntpd had a public key encryption scheme where we just need the secret key on the server[1] and the public key can be general for all Debian users.  (I think that's the 'autokey' scheme -- the "trustedkey/requestkey" stuff is where you share a secret between client and server).


Ask

[1] But those servers obviously have to be run by especially trusted people as they need to know the secret and be okay with the increased resource requirements etc.  I figure in the Debian community you could find/pick a few dozen servers suitable for that which likely would be enough.

Message #45 received at 687166@bugs.debian.org (full text, mbox, reply):

From: Nico Golde <nion@debian.org>

To: Ask Bjørn Hansen <ask@ntppool.org>

Cc: Kurt Roeckx <kurt@roeckx.be>, 687166@bugs.debian.org, none <anotst01@fastmail.fm>

Subject: Re: [pkg-ntp-maintainers] Bug#687166: ntp: NTP security vulnerability because not using authentication by default

Date: Tue, 11 Sep 2012 12:49:09 +0200

[Message part 1 (text/plain, inline)]

Hi,
* Ask Bjørn Hansen <ask@ntppool.org> [2012-09-11 01:01]:
> On Sep 10, 2012, at 15:07, Kurt Roeckx <kurt@roeckx.be> wrote:
> [...]
> > So my understanding of things is that even if we also had
> > a way to distribute all the public keys, you still can't
> > get it to work as you need to provide each client with
> > a secret key.
> > 
> > I think what first needs to be done is have an autokey
> > implementation that either doesn't need a private key for
> > each client but is secure or doesn't need state on the
> > server side for each client.
> 
> Indeed; I thought ntpd had a public key encryption scheme where we just need 
> the secret key on the server[1] and the public key can be general for all 
> Debian users.  (I think that's the 'autokey' scheme -- the 
> "trustedkey/requestkey" stuff is where you share a secret between client and 
> server).

That was my understanding as well. At least the documentation states:
"key pairs are used where establishing shared secrets is difficult. The 
autokey mechanism uses key pairs.".

Cheers
Nico

[Message part 2 (application/pgp-signature, inline)]

Message #50 received at 687166@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Nico Golde <nion@debian.org>

Cc: Ask Bjørn Hansen <ask@ntppool.org>, 687166@bugs.debian.org, none <anotst01@fastmail.fm>

Subject: Re: [pkg-ntp-maintainers] Bug#687166: ntp: NTP security vulnerability because not using authentication by default

Date: Tue, 11 Sep 2012 21:23:45 +0200

On Tue, Sep 11, 2012 at 12:49:09PM +0200, Nico Golde wrote:
> Hi,
> * Ask Bjørn Hansen <ask@ntppool.org> [2012-09-11 01:01]:
> > On Sep 10, 2012, at 15:07, Kurt Roeckx <kurt@roeckx.be> wrote:
> > [...]
> > > So my understanding of things is that even if we also had
> > > a way to distribute all the public keys, you still can't
> > > get it to work as you need to provide each client with
> > > a secret key.
> > > 
> > > I think what first needs to be done is have an autokey
> > > implementation that either doesn't need a private key for
> > > each client but is secure or doesn't need state on the
> > > server side for each client.
> > 
> > Indeed; I thought ntpd had a public key encryption scheme where we just need 
> > the secret key on the server[1] and the public key can be general for all 
> > Debian users.  (I think that's the 'autokey' scheme -- the 
> > "trustedkey/requestkey" stuff is where you share a secret between client and 
> > server).
> 
> That was my understanding as well. At least the documentation states:
> "key pairs are used where establishing shared secrets is difficult. The 
> autokey mechanism uses key pairs.".

So after reading some more, I think the only option we have is
using the IFF identity scheme.

But I seem to be failing in getting it working.


Kurt

Message #55 received at 687166@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Nico Golde <nion@debian.org>

Cc: none <anotst01@fastmail.fm>, 687166@bugs.debian.org, Ask Bjørn Hansen <ask@ntppool.org>

Subject: Re: [pkg-ntp-maintainers] Bug#687166: Bug#687166: ntp: NTP security vulnerability because not using authentication by default

Date: Tue, 18 Sep 2012 22:03:05 +0200

On Tue, Sep 11, 2012 at 09:23:45PM +0200, Kurt Roeckx wrote:
> 
> So after reading some more, I think the only option we have is
> using the IFF identity scheme.
> 
> But I seem to be failing in getting it working.

So the problem is that autokey does not work over NAT.  So I don't
think it's going to be a good idea to try to turn this on by
default.


Kurt

Message #60 received at 687166@bugs.debian.org (full text, mbox, reply):

From: anotst01@fastmail.fm

To: Kurt Roeckx <kurt@roeckx.be>, Nico Golde <nion@debian.org>

Cc: 687166@bugs.debian.org, Ask Bjørn Hansen <ask@ntppool.org>

Subject: Re: [pkg-ntp-maintainers] Bug#687166: Bug#687166: ntp: NTP security vulnerability because not using authentication by default

Date: Tue, 18 Sep 2012 20:12:47 -0700

On Tue, Sep 18, 2012, at 01:03 PM, Kurt Roeckx wrote:
> On Tue, Sep 11, 2012 at 09:23:45PM +0200, Kurt Roeckx wrote:
> > 
> > So after reading some more, I think the only option we have is
> > using the IFF identity scheme.
> > 
> > But I seem to be failing in getting it working.
> 
> So the problem is that autokey does not work over NAT.  So I don't
> think it's going to be a good idea to try to turn this on by
> default.

Agreed. What else could we do?

NTP upstream bug report?

Or a more general debian bug "need secure replacement for NTP"? Against
which component?

-- 
http://www.fastmail.fm - One of many happy users:
  http://www.fastmail.fm/docs/quotes.html

Send a report that this bug log contains spam.