NTP vulnerable - not using authentication by default

[adrelanos]

Hi!

Cryptographic verification generally works well but there is one big
drawback: it requires correct date/time.

NTP in Qubes OS 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
(Qubes OS specific or not). 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.

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

It would be great if you could do something about it.

Cheers!
adrelanos

[tun...@hot.ee]

There are two vectors under discussion. First one: how the external time arrives at the physical machine. The second one: how the precise time gets distributed from FW to any of the virtual machines.

Look at this: http://blog.ine.com/2007/12/28/how-does-ntp-authentication-work/
but there are plenty of others.

Generally, it is not a problem to agree ntp auth in office conditions. For a travelling laptop, scenarios are more diverse, involving e.g. timesync via VPN channel.

The key question (as with any crypto) is, with *whom* you agree the keys and whether (or not) you trust him/her/it.

Within Qubes-OS one probably has to trust himself/herself/itself thus agreeing the keys should be especially easy.

Last but not least, standard NTP configurations only permit time drifts within 1h if not even 30 min. No years.

Tunguuz.
Sent from my android device.

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Joanna Rutkowska]

On 02/06/13 00:40, adrelanos wrote:
> Hi!
>
> Cryptographic verification generally works well but there is one big
> drawback: it requires correct date/time.
>

Hm... in many cases not. Sure, it can make the already expired cert/key
to be treated as valid, however if I already have imported a revokation
certificate, then I think the date setting should have no impact, the
old key/cert should always be treated as invalid. At least I believe
this should be the case of gpg and openssl certs, no?

> NTP in Qubes OS 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
> (Qubes OS specific or not). 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.
>
> Putting the clock several years back allows an adversary to use already
> revoked, broken, expired certificates; replay old, broken, outdated,
> known vulnerable updates etc.
>
> It would be great if you could do something about it.
>

Where can one get public key certficates for public NTP servers?

How about you send some patches to add this support?

joanna.

[Joanna Rutkowska]

On 02/06/13 01:03, tun...@hot.ee wrote:
> There are two vectors under discussion. First one: how the external
> time arrives at the physical machine. The second one: how the precise
> time gets distributed from FW to any of the virtual machines.
>
> Look at this:
> http://blog.ine.com/2007/12/28/how-does-ntp-authentication-work/ but
> there are plenty of others.
>
> Generally, it is not a problem to agree ntp auth in office
> conditions. For a travelling laptop, scenarios are more diverse,
> involving e.g. timesync via VPN channel.
>
> The key question (as with any crypto) is, with *whom* you agree the
> keys and whether (or not) you trust him/her/it.
>

We just need a way to obtain certificates for several public, well known
NTP servers, right? Any idea where to get those?

> Within Qubes-OS one probably has to trust himself/herself/itself thus
> agreeing the keys should be especially easy.
>

Not sure what you mean by that? We need a verified public key of some
external NTP server, such as e.g. time.nist.gov.

> Last but not least, standard NTP configurations only permit time
> drifts within 1h if not even 30 min. No years.
>

Not in a default configuration as we use in Qubes. We actually use
ntpdate for triggering time sync and it doesn't observe any time
limitations:

[root@work-pub ntp]# date -s "Apr 1 2019"
Mon Apr 1 00:00:00 CEST 2019
[root@work-pub ntp]# ntpdate pool.ntp.org
6 Feb 11:17:46 ntpdate[3820]: step time server 194.29.130.252 offset
-193923746.522322 sec
[root@work-pub ntp]# date
Wed Feb 6 11:17:53 CET 2013


joanna.

[adrelanos]

Joanna Rutkowska:

> On 02/06/13 00:40, adrelanos wrote:
>> Hi!
>>
>> Cryptographic verification generally works well but there is one big
>> drawback: it requires correct date/time.
>>
> Hm... in many cases not. Sure, it can make the already expired cert/key
> to be treated as valid, however if I already have imported a revokation
> certificate, then I think the date setting should have no impact, the
> old key/cert should always be treated as invalid. At least I believe
> this should be the case of gpg and openssl certs, no?

Haven't researched that in detail, but the SSL certificate revocation
process is said to be broken. Most CA's don't use it.

http://www.imperialviolet.org/2011/03/18/revocation.html

http://arstechnica.com/business/2012/02/google-strips-chrome-of-ssl-revocation-checking/

There is also a stale mirror attack (don't know if Fedora is affected):
https://bugs.launchpad.net/launchpad/+bug/716535

>> NTP in Qubes OS 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
>> (Qubes OS specific or not). 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.
>>
>> Putting the clock several years back allows an adversary to use already
>> revoked, broken, expired certificates; replay old, broken, outdated,
>> known vulnerable updates etc.
>>
>> It would be great if you could do something about it.
>>
> Where can one get public key certficates for public NTP servers?

No idea if there finally is a free public NTP server offering
authentication. Few months ago I checked and there was none.

> How about you send some patches to add this support?

All I can offer right now is ideas, problem description, links and
solution proposals. Programming it myself would be interesting, but I
don't have the skills yet.

Looks like this also involves social skills. It's not something I could
do alone. Unfortunately, I failed understanding the authenticated NTP
guide and there was no help on the mailing list. No one really seems to
know. If that succeeded, I could have asked some people to host free
public authenticated NTP servers. Jacob Appelbaum would do it, perhaps
others, but he wants instructions, I am unable to deliver.

Other than confirmed bugs, I haven't reached anything. People looked
into it, then lost interest or had no idea how to solve it.
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23687166
- https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1039420

When I find time, I try to get sdwdate into Debian.
https://github.com/adrelanos/sdwdate

It's basically tails_htp (which is based on htpdate).
https://tails.boum.org/contribute/design/Time_syncing/

It's a distributed and authenticated system. Extracts time stamps from
SSL, asks three servers and builds the median.

Since SSL (with current CA system) is also not that secure and NTP has
no distributed trust scheme (unless someone patches it), these are all
imperfect solutions.

The Tor network could be used to get the time as well. They should fix
it anyway:
https://trac.torproject.org/projects/tor/ticket/8170

The idea was, the Tor network has ~3000 relays and relays could tell the
time either directly or using a torified connection. So I requested a
feature:
https://trac.torproject.org/projects/tor/ticket/6894

Was reviewed as good idea by a Tails developer.
https://tails.boum.org/todo/robust_time_syncing/

That feature would be a good base for a distributed and authenticated
network time synchronization mechanism. But not everyone wants to use
Tor. So this isn't a perfect solution either.

While I have an overview and some solutions, I can't write the necessary
patches for upstream projects (example: distributed, authenticated NTP),
talk them into merging and using, neither patch the linux distributions.

So I thought, why not report a bug. I report the bug, fixing it is
another question. :) Perhaps someone with a fresh perspective has a
better idea. Either it gets fixed or ignored. But no one can say, I
didn't mention it.

[Joanna Rutkowska]

Perhaps the simple countermeasure of preventing ntpdate from taking time
backwards more than MAX_HOURS_BACKWARDS would be enough?

I guess one could just add such a check to this script:

http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=qubes_rpc/sync-ntp-clock;h=f5dfa1bb66b720c6ac9d3bcf2ca5aab22f1b6ec2;hb=HEAD

?