4 ms·

Okay, so I changed the year to 2039, started WindowsXP in VirtualBox. Nothing happend. Opened Excel, typed in some time-related functions (like NOW), worked fin

by snitko 18y ago

Okay, so I changed the year to 2039, started WindowsXP in VirtualBox. Nothing happend. Opened Excel, typed in some time-related functions (like NOW), worked fine. And just by the time I was going to post this message ending with "What is wrong with it, I want some blue screen people" I simply couldn't log in with my LiveJournal openID (not sure if this is HN's or LJ's fault), so seems like this time thing really works.

allenbrunson 18y ago
i suspect that windows' low-level timekeeping is not based on time_t, the way unix is. windows has a bunch of stuff like the SYSTEMTIME struct that does not exist on unix-like operating systems and doesn't have the same vulnerabilities. so windows-only software is less likely to exhibit this problem. macosx/linux/unix is much more severely affected. however, microsoft's c/c++ compiler does indeed recognize time_t and related functions. any software that uses them will be subject to the 2038 problem.
jwilliams 18y ago
I simply couldn't log in with my LiveJournal openID Perhaps an SSL certificate thing? If you wind your clock forward enough it's past the expiry of SSL certificates.
- tlrobinson 18y ago
  Yeah that's likely the issue. Actually, looking at all the root CA certs on my computer (OS X, look in Keychain.app if you're curious) every single one of them (except one) expires in 2037 or earlier. This is almost certainly not a coincidence. In software that doesn't take the Y2K38 issue into account the expiration date would wrap around to an earlier date, causing the software to think the cert is invalid.
  - jwilliams 18y ago
    Ah ok - yeah, I've hit that issue in testing before. I'd be surprised if 2038 was the reason though - most certificates are very conservative about expiry. You'd never have a cert that lasts to 2038 as there is a high probability that the cert would be cracked well before that date (i.e. even if it's brute-force, likely computers in "n" years time will be able to crack it).
    - tlrobinson 18y ago
      I would have thought that too, except there's a bunch of certs with expirations all the way up to 2037 at which point they abruptly stop (except for the one 2040)... http://tlrobinson.net/skitches/Keychain_Access-20090106-000936.png http://tlrobinson.net/skitches/Keychain_Access-20090106-0009...
- snitko 18y ago
  Wait. What certificate? There were no https connections. Of course, cookies would expire, but what does it have to do with not being able to login again?
- andyking 18y ago
  My mobile phone's old and decrepit and often loses its date and time, going back to November 2005 for reasons known only to itself. The first I know of it, Opera Mini is refusing to connect to the web. I always wondered why that should be the case - thanks!
paraschopra 18y ago
Did anyone did this with Linux?
- snitko 18y ago
  I'm actually on Linux, except that it's x86_64. WinXP was in VirtualBox.

by snitko 18y ago

allenbrunson 18y ago

i suspect that windows' low-level timekeeping is not based on time_t, the way unix is. windows has a bunch of stuff like the SYSTEMTIME struct that does not exist on unix-like operating systems and doesn't have the same vulnerabilities. so windows-only software is less likely to exhibit this problem. macosx/linux/unix is much more severely affected. however, microsoft's c/c++ compiler does indeed recognize time_t and related functions. any software that uses them will be subject to the 2038 problem.

jwilliams 18y ago

I simply couldn't log in with my LiveJournal openID Perhaps an SSL certificate thing? If you wind your clock forward enough it's past the expiry of SSL certificates.

tlrobinson 18y ago
Yeah that's likely the issue. Actually, looking at all the root CA certs on my computer (OS X, look in Keychain.app if you're curious) every single one of them (except one) expires in 2037 or earlier. This is almost certainly not a coincidence. In software that doesn't take the Y2K38 issue into account the expiration date would wrap around to an earlier date, causing the software to think the cert is invalid.
- jwilliams 18y ago
  Ah ok - yeah, I've hit that issue in testing before. I'd be surprised if 2038 was the reason though - most certificates are very conservative about expiry. You'd never have a cert that lasts to 2038 as there is a high probability that the cert would be cracked well before that date (i.e. even if it's brute-force, likely computers in "n" years time will be able to crack it).
  - tlrobinson 18y ago
    I would have thought that too, except there's a bunch of certs with expirations all the way up to 2037 at which point they abruptly stop (except for the one 2040)... http://tlrobinson.net/skitches/Keychain_Access-20090106-000936.png http://tlrobinson.net/skitches/Keychain_Access-20090106-0009...
snitko 18y ago
Wait. What certificate? There were no https connections. Of course, cookies would expire, but what does it have to do with not being able to login again?
andyking 18y ago
My mobile phone's old and decrepit and often loses its date and time, going back to November 2005 for reasons known only to itself. The first I know of it, Opera Mini is refusing to connect to the web. I always wondered why that should be the case - thanks!

paraschopra 18y ago

Did anyone did this with Linux?

snitko 18y ago
I'm actually on Linux, except that it's x86_64. WinXP was in VirtualBox.