Comment 6 for bug 104525

Alexander Konovalenko <email address hidden> writes:
> I'm concerned with the security implications of using a pool of unknown
> time servers per default.

Most other OSes out there do this or variations on it now, so it would
hardly be an Ubuntu specific problem.

There are only security problems for Kerberos based services. If
you're using Kerberos, you had better be set up to use NTP one way or
another anyway, and probably a custom setup. If you're not already
using ntp, your kerberos setup won't work at all.

> If I understand correctly, anyone can volunteer to participate in
> the pool. If the end user's ntpd is started with the -g option,
> overriding the 1000 seconds sanity check (as was the default in
> Ubuntu 7.10),

The default can always be changed, of course, but I think it hardly
matters.

> and the server selects only one time server from the pool to
> synchronize from,

That's a big if. If you have three servers in your list, the odds of
all three being suborned are minimal. The odds of an attacker being
able to influence which clients end up getting pointed to them in the
DNS are also minimal. Beyond that, there is the fact that there are
generally no real security implications to having your clock altered.

> an attacker who controls a single server in the pool can set the
> time of many Ubuntu hosts over the world.

Yes. That's hardly a problem.

> Also, he will know the IP addresses of the victims.

Not really. He'll only know they asked his machine for time -- he has
no way of knowing if they actually set the time (especially if they
have other servers giving different numbers) and he has no real way to
exploit any of this anyway.

> If any of them happen to be interesting targets for the attacker, he
> can then mount further attacks on all cryptographic protocols that
> depend on correct time-keeping

Which protocols would those be? I don't think Ubuntu ships with any
kerberos enabled apps, and even for kerberos the attacks are minimal,
since the clock is only used for ticket expiry.

> (for example, to prevent replay attacks).

TLS and IPsec use entirely different mechanisms to prevent
replay. There are no clock dependent security protocols in real use
that I'm aware of other than Kerberos. Even for Kerberos, trying to
set a clock far off is only going to allow an attacker to extend a
ticket, it won't actually allow important remotely exploitable
attacks. I can post references on this if needed.

> That would be a serious security threat for the users.

I do security for a living. I see no threat here, and certainly no
serious threat.

If you are really concerned about security, worry about real problems
in the default Ubuntu config, like turning zeroconf on by default,
which expose people to actual problems. This "threat" you are worried
about in setting a default ntp.conf is not real.

Perry