4 ms·

I don't understand what attacks are possible... making an enemy late for work when his alarm goes off several hours late? Or can you circumvent certificate rev

I don't understand what attacks are possible... making an enemy late for work when his alarm goes off several hours late? Or can you circumvent certificate revocations this way?

Ricapar 12y ago
There is still a lot of crypto out there that works off of using the current timestamp as a seed. Being able to control he time could theoretically let you control any PRNGs that rely on it.
- dvanduzer 12y ago
  The much bigger issue is with hardware that doesn't have a local clock/battery. Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.
  - cbsmith 12y ago
    > The much bigger issue is with hardware that doesn't have a local clock/battery. Ummm, no. NTP normally runs on machines that have a local clock/battery, but which need an established network clock anyway. > Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token. Using time as a random seed is probably a mistake in the first place. You could perhaps try to add entropy from a clock, but you'd want another source of entropy. Generally crypto code needs network clocks for other things (think of Kerberos ticket expiration).
    - dvanduzer 12y ago
      The average longevity of a Kerberos ticket makes it the perfect example for this attack vector, actually. Are you familiar with something other than NTP as a time source for devices without CMOS? I have a project that desperately needs crypto without a clock.
      - cbsmith 12y ago
        If you are really worried, use layer 3 or layer 2 security (say with IPSec) to secure NTP communications. Yes, there is a bit of a bootstrapping problem, but you can address that with a bootstrapped handshake that sets a clock baseline. Alternatively, you could just hardwire a radio receiver (like say... a GPS receiver).
- tedunangst 12y ago
  I don't think I need to control your clock when I can just look at my watch and know what your clock says. Why do things the hard way?
  - cbsmith 12y ago
    Because any cryptographic implementation worth its salt wouldn't be using even second resolution time, so what your watch says is irrelevant. Also, if I cracked an NTP feed, I'd not use it to know what the server's clock is set to so much as to manipulate the server's clock to all kinds of wonderful effect.
    - dvanduzer 12y ago
      You're misunderstanding the attack vector. The exploit is about precisely controlling the delta between a client and server. There is no problem with using low-resolution time signatures as a cryptographic seed. Using time as an entropy source is only a problem if you sample at a lower resolution than your clock's error rate.
      - cbsmith 12y ago
        Maybe I wasn't clear, but I was thinking one would manipulate the delta specifically to cause the machine to adjust its clock.
- cbsmith 12y ago
  It's more than that. There is tons of logic in crypto protocols around timeouts, and of course services themselves often have bugs around the handling of time (there's a great list of assumptions developers make about time that are fatal and create all kinds of security problems).
BreaXerox 12y ago
Accurate time is pretty important to computers. An attacker that can skew time can bypass HSTS, expire cookies, etc.
agwa 12y ago
You could circumvent certificate revocations by replaying expired OCSP Staple responses that say a certificate is not revoked. You could also cause expired certificates to be accepted, which limits the utility of short-lived certs as a means of protecting against key compromise. And as hannob said, you can circumvent HSTS by setting the time in the future, causing all HSTS entries to be expired.
- tedunangst 12y ago
  Pretty persistent attacker. It should take something like 100 days to push the clock off by one day.
  - hannob 12y ago
    Ubuntu accepts arbitrary time jumps, the attack was presented live at BH with an Ubuntu System.
    - protomyth 12y ago
      so you can see Ubuntu so it is 03:14 UTC on 19 January 2038? That might be bad, how big is their time_t?
- dvanduzer 12y ago
  This kind of attack should be difficult, because NTP clients should be configured to ignore large offsets. See the (dangerous) -g option in the ntpd manpage, for example.
- xorcist 12y ago
  For that to work you need to compromise _all_ the NTP servers those servers sync to for an extended period of time (years). It's simply not a realistic attack. NTP does not sync time. NTP measures time drift across groups of servers, and sprinkles in known time. I'm not saying authentication is useless, you should turn it on for your known time sources, but it's not so simple as you make it out to be. Unless you use SNTP on your servers. Don't do that. Ever.

I don't understand what attacks are possible... making an enemy late for work when his alarm goes off several hours late? Or can you circumvent certificate revocations this way?

Ricapar 12y ago

There is still a lot of crypto out there that works off of using the current timestamp as a seed. Being able to control he time could theoretically let you control any PRNGs that rely on it.

dvanduzer 12y ago
The much bigger issue is with hardware that doesn't have a local clock/battery. Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.
- cbsmith 12y ago
  > The much bigger issue is with hardware that doesn't have a local clock/battery. Ummm, no. NTP normally runs on machines that have a local clock/battery, but which need an established network clock anyway. > Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token. Using time as a random seed is probably a mistake in the first place. You could perhaps try to add entropy from a clock, but you'd want another source of entropy. Generally crypto code needs network clocks for other things (think of Kerberos ticket expiration).
  - dvanduzer 12y ago
    The average longevity of a Kerberos ticket makes it the perfect example for this attack vector, actually. Are you familiar with something other than NTP as a time source for devices without CMOS? I have a project that desperately needs crypto without a clock.
    - cbsmith 12y ago
      If you are really worried, use layer 3 or layer 2 security (say with IPSec) to secure NTP communications. Yes, there is a bit of a bootstrapping problem, but you can address that with a bootstrapped handshake that sets a clock baseline. Alternatively, you could just hardwire a radio receiver (like say... a GPS receiver).
tedunangst 12y ago
I don't think I need to control your clock when I can just look at my watch and know what your clock says. Why do things the hard way?
- cbsmith 12y ago
  Because any cryptographic implementation worth its salt wouldn't be using even second resolution time, so what your watch says is irrelevant. Also, if I cracked an NTP feed, I'd not use it to know what the server's clock is set to so much as to manipulate the server's clock to all kinds of wonderful effect.
  - dvanduzer 12y ago
    You're misunderstanding the attack vector. The exploit is about precisely controlling the delta between a client and server. There is no problem with using low-resolution time signatures as a cryptographic seed. Using time as an entropy source is only a problem if you sample at a lower resolution than your clock's error rate.
    - cbsmith 12y ago
      Maybe I wasn't clear, but I was thinking one would manipulate the delta specifically to cause the machine to adjust its clock.
cbsmith 12y ago
It's more than that. There is tons of logic in crypto protocols around timeouts, and of course services themselves often have bugs around the handling of time (there's a great list of assumptions developers make about time that are fatal and create all kinds of security problems).

BreaXerox 12y ago

Accurate time is pretty important to computers. An attacker that can skew time can bypass HSTS, expire cookies, etc.

agwa 12y ago

You could circumvent certificate revocations by replaying expired OCSP Staple responses that say a certificate is not revoked. You could also cause expired certificates to be accepted, which limits the utility of short-lived certs as a means of protecting against key compromise. And as hannob said, you can circumvent HSTS by setting the time in the future, causing all HSTS entries to be expired.

tedunangst 12y ago
Pretty persistent attacker. It should take something like 100 days to push the clock off by one day.
- hannob 12y ago
  Ubuntu accepts arbitrary time jumps, the attack was presented live at BH with an Ubuntu System.
  - protomyth 12y ago
    so you can see Ubuntu so it is 03:14 UTC on 19 January 2038? That might be bad, how big is their time_t?
dvanduzer 12y ago
This kind of attack should be difficult, because NTP clients should be configured to ignore large offsets. See the (dangerous) -g option in the ntpd manpage, for example.
xorcist 12y ago
For that to work you need to compromise _all_ the NTP servers those servers sync to for an extended period of time (years). It's simply not a realistic attack. NTP does not sync time. NTP measures time drift across groups of servers, and sprinkles in known time. I'm not saying authentication is useless, you should turn it on for your known time sources, but it's not so simple as you make it out to be. Unless you use SNTP on your servers. Don't do that. Ever.