Lucene search
K

nt4+sp4.y2k.txt

🗓️ 17 Aug 1999 00:00:00Reported by Packet StormType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 21 Views

Y2K problem found in NT SP4; clock fails to advance correctly during file copies in 2000.

Code
`Date: Tue, 23 Mar 1999 18:31:34 -0500  
From: Ilya Slavin <[email protected]>  
To: [email protected]  
Subject: NT Y2K issue (post SP4)  
  
  
Those of you who are in the process of deploying SP4 or are  
planning to do so should be aware that a new Y2K problem was discovered  
in this service pack.  
Here's the scoop. In the course of Y2K testing of Windows NT server and  
workstation, I patched the OS and all applications to their vendor  
recommended Y2K levels (that included SP4 on both types of systems as  
well as other fixes on the workstation). The test itself was to set  
the clock 30 seconds prior to midnight on December 31, 1999 and initiate  
a large file copy (by right-clicking on the initial file in Explorer,  
selecting copy, and then paste in the destination folder). The object  
was to have the copy process complete in 2000. This way the new file  
creation date would be in one year, and the last access date will be in  
the next.  
What I discovered was very troubling. On several attempts to run the  
test, both NT Server and NT Workstation (on two different computers)  
failed to roll the clock into the next year (while succeeding on most  
other attempts). Instead they went from 11:59:59PM on December 31st,  
1999 to 12:00:00PM of the same day, thus adding another 12 hours to it.  
The first time I saw this I thought I made a mistake and set the clock  
to AM instead of PM, but the file creation date showed that it was  
indeed set correctly.  
These results were confirmed by Russ Cooper (the moderator of this  
mailing list) with a few twists: sometimes the clock can go forward by  
12 hours instead of back. Also, it appears that this problem does not  
happen when you use the copy command from the DOS shell. After Russ'  
notes were added to the case I opened earlier with Microsoft (although I  
myself wasn't able to persuade the vendor the problem actually existed),  
a bug number was assigned to this issue. However, as of the time of  
this writing, we remain in the dark as to how far Microsoft has gotten  
with the test.  
While this may not seem like a very big deal, this bug may be troubling.  
Depending on the system call that triggers this problem (there have to  
be over a good dozen different ones occurring in the process of a file  
copy), this may turn out to be a serious problem.  
Please keep in mind that Microsoft is claiming commitment to Service  
Pack 4's Y2K compliance (as well as Service Pack 3's compliance "with  
minor issues"). So if they do confirm that this is a problem, they will  
likely issue a hot fix to existing Service Packs. Thus it may not be  
necessary to halt all SP4 deployment and wait for the next Service Pack,  
but you may find it helpful to keep the information provided in this  
message in mind as you plan deployment.  
As more details emerge, we'll post them to this list, but for the time  
being, it does not appear that SP4 is entirely Y2K compliant as was  
originally stated. I would also like to hear from anyone who was able  
to reproduce this problem - the more reports there are, the greater the  
chance that Microsoft will address this issue in a timely fashion.  
  
Ilya Slavin  
System Administrator  
Tudor Investment Corporation  
  
--------------------------------------------------------------------------  
  
Date: Tue, 23 Mar 1999 17:06:18 -0800  
From: Jason Garms <[email protected]>  
To: [email protected]  
Subject: Re: NT Y2K issue (post SP4)  
  
We still have not been able to reproduce this reported bug under numerous  
system configurations, either using information supplied by Ilya, or with  
additional information from Russ. We are continuing to evaluate this and  
trying different system configurations to try to reproduce it. Thanks to  
Russ for his time today working with us on this.  
  
We would welcome any additional information that can be supplied on how to  
reproduce this bug. Please direct this info to our y2k reporting alias:  
[email protected].  
  
Thanks,  
-jasong  
  
Jason Garms  
Windows NT Security  
Microsoft Corporation  
  
  
-----Original Message-----  
>From: Ilya Slavin [mailto:[email protected]]  
Sent: Tuesday, March 23, 1999 3:32 PM  
To: [email protected]  
Subject: NT Y2K issue (post SP4)  
  
  
Those of you who are in the process of deploying SP4 or are  
planning to do so should be aware that a new Y2K problem was discovered  
in this service pack.  
  
[text deleted...]  
  
As more details emerge, we'll post them to this list, but for the time  
being, it does not appear that SP4 is entirely Y2K compliant as was  
originally stated. I would also like to hear from anyone who was able  
to reproduce this problem - the more reports there are, the greater the  
chance that Microsoft will address this issue in a timely fashion.  
  
Ilya Slavin  
System Administrator  
Tudor Investment Corporation  
  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation

17 Aug 1999 00:00Current
7.4High risk
Vulners AI Score7.4
21