Subject: Log time stamp inconsistency (Y2K)

From: "Vincent J. Troisi" <[email-masked]>
Date: Mon, 16 Aug 1999 08:58:11 -0600

Hi!

I had an interesting result when we performed our Y2K validation.
We are running Version wu-2.1c(2) as our ftp server on an
SGI Challenge (IRIX 5.3). The SGI OS has been patched to
handle Y2K issues.

Our test for ftp compliance was performed by
synching the dates on a client and our ftp server;
both systems had dates set to March 1 2000.
A file was transferred to the ftp server. The time
stamp of the file was correct (Mar 1 2000 00:13) but
the entry in the xferlog file had a transfer time of
March 2 2000 00:13! Has anyone else attempted
a similar test and had similar or differing results?

-- 
__________________________________________________________________________

Vincent J. Troisi					
University of Colorado			
CIRES/NSIDC				Phone: 303.492.1827
Campus Box 449				Fax:   303.492.2468
Boulder, CO 80309-0449			Email: [email-masked]
__________________________________________________________________________

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 16 Aug 1999 12:05:31 -0400

On Mon, Aug 16, 1999 at 08:58:11AM -0600, Vincent J. Troisi wrote:

> I had an interesting result when we performed our Y2K validation.  We are
> running Version wu-2.1c(2) as our ftp server on an SGI Challenge (IRIX
> 5.3). The SGI OS has been patched to handle Y2K issues.
> 
> Our test for ftp compliance was performed by synching the dates on a
> client and our ftp server; both systems had dates set to March 1 2000.  A
> file was transferred to the ftp server. The time stamp of the file was
> correct (Mar 1 2000 00:13) but the entry in the xferlog file had a
> transfer time of March 2 2000 00:13! Has anyone else attempted a similar
> test and had similar or differing results?

I cannot imagine why anyone would bother.

Your system is so old and has such severe security problems, I'm sure the
hackers using it (and I'd not be surprised to learn there's been a few
thousand of them) just chuckle and overwrite your system logs using the
lame dates so you'll not notice.  That's if they even both letting you see
your system logs.

For purely acedemic reasons, if you actually have the _original_ source kit
to a version of the deamon that old, I'd be interested in adding it to the
attic area of the ftp site .. not that anyone would ever want to use it,
but it might be nice to have some of the old, lost code like you're running
in case someone wants to know when Bryon added a particular feature.

In the meantime, I STRONGLY suggest you completely disconnect that computer
from ALL networks and IMMEDEATELY begin the process of regaining control of
your computer.  If you need assistance, there's a good reference on
'Detecting and Recovering from a Root Compromise' at http://www.CERT.org/

Online resources, including the latest version of the daemon, are available
through:
 
      http://www.wu-ftpd.org/

-- 

Gregory A Lundberg              WU-FTPD Development Group
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: Bob Luckin <[email-masked]>
Date: Mon, 16 Aug 1999 16:58:31 CDT

Vincent wrote :-
> a similar test and had similar or differing results?

I haven't tried this, but...

Version wu-2.1c is _very_ old (circa 1993 or 1994 I think), and has some
known security flaws, so you might want to consider upgrading to the latest
release (2.5.0).

Having said that, both 2.1c and 2.5.0 generate the date for the xferlog by
calling time()
   time_t curtime = time(NULL);
and later on calling sprintf, and supplying a format of "%.24s" with the
output of a call to ctime...

2.1c :-
   sprintf(msg, "%.24s %d %s %d %s %c %s %c %c %s ftp %d %s\n",
           ctime(&curtime),
           ...

2.5.0 :-
   sprintf(msg, "%.24s %d %s %" L_FORMAT " ",
           ctime(&curtime),
   ...

(It was discovered that sprintf() under some OS's was quite limited in the
number of parameters it could be passed; hence the reason the 2.5.0 call is
a shorter format string - the output gets concatenated with a subsequent
sprintf() call which produces the rest of the string.)

This makes me believe that upgrading to 2.5.0 may not fix the problem;
I wonder if IRIX 5.3 ineeds another patch to fix ctime()...  You could write
a small stand-alone program to test this hypothesis.

Of course, you may want to upgrade to 2.5.0 for other reasons, since you are
running such an old version at present.

Good luck !

Cheers, Bob
-- 
Bob Luckin      [email-masked]      "Coder, adapt.  FTP Ada, redo C."