[CLUE-Tech] stat(2) and ctime st_ctime changes?

[Jim Ockers]

Hi group,

I'd like to bounce this situation off you.  We have a server that
runs tripwire enterprise for IDS.  It recently generated several
thousand critical errors in a tripwire report, and I was assigned
to investigate.

In each case the file was exactly the same size and contents as 
the original file, and the owner/group/links/inode/mtime were all 
the same as well.  The only thing that changed was the "change time"
or ctime.

According to stat(2) these are the possible attributes of a file:

              struct stat {
                  dev_t         st_dev;      /* device */
                  ino_t         st_ino;      /* inode */
                  mode_t        st_mode;     /* protection */
                  nlink_t       st_nlink;    /* number of hard links */
                  uid_t         st_uid;      /* user ID of owner */
                  gid_t         st_gid;      /* group ID of owner */
                  dev_t         st_rdev;     /* device type (if inode device) */
                  off_t         st_size;     /* total size, in bytes */
                  blksize_t     st_blksize;  /* blocksize for filesystem I/O */
                  blkcnt_t      st_blocks;   /* number of blocks allocated */
                  time_t        st_atime;    /* time of last access */
                  time_t        st_mtime;    /* time of last modification */
                  time_t        st_ctime;    /* time of last change */
              };

The man page goes on to say:
	The field st_ctime is changed by writing or by setting inode 
	information (i.e., owner, group, link count, mode, etc.).

Since the ctime is changed but absolutely nothing else about the
file is changed (including the MD5 hash value), would it be correct
to say that one of the following was reset to its original value?

mode_t
nlink_t
uid_t
gid_t
st_ctime (reset to the new ctime of course, otherwise we would
	not have noticed the change)

The reason I ask is that "etc." there in the man page makes me
nervous.  What else might change that could cause a ctime change,
that's not listed in the struct stat?

We are not able to identify any unusual activity on the server
during this time, and it turns out that the ctime values that it
flagged are in sequential order a second a part as if something
walked the filesystem and touch(1) each file, or something.  I know
it wasn't touch(1) because that resets the mtime.

This is unusual and I'd appreciate any ideas you have as to
what might cause ctime to change for a bunch of files but nothing
else to change.

Thanks a lot,
Jim

PS I didn't actually review every file so it's possible that a
crafty attacker modified one file and changed ctime on a whole bunch
of other files in the hopes that we wouldn't notice the one that
actually changed in the huge tripwire report that would result.
However I did a thorough review and nothing else seems amiss on 
the system.

PPS We are also asking tripwire about this.

-- 
Jim Ockers, P.Eng. (ockers at ockers.net)
Contact info: please see http://www.ockers.net/