COMMAND

    kernel

SYSTEMS AFFECTED

    FreeBSD 2.2.6-RELEASE

PROBLEM

    Following has serious security implications; even if it turns  out
    to be  the case  that the  contents of  the file  aren't modified,
    having  the  time  stamp  pseudo-randomly  change  would make just
    about any sysadmin  go into a  fit of paranoia.   It was found  by
    Robert Withrow.

    He was debugging  a (large) program  using GDB on  an xterm (which
    prevented him from getting the exact text, as you will see).  This
    was on 2.2.6-RELEASE on a P6-200  with 128M ram as a normal  user.
    After issued the "run" command GDB said that  /usr/lib/libc.so.3.1
    had  changed  and  it  was  re-loading  it.   That  was   followed
    immediately by X freezing, and then a spontaneous re-boot.   After
    the system re-booted, sure enough the date on /usr/lib/libc.so.3.1
    had been changed!

    Now, with this program, GDB generally says that the *program*  has
    changed *every* time you issue the "run" command.  The question is
    how GDB can override protections on /usr/lib/libc.so.3.1 in  order
    to change its date.  It is a bug in the FreeBSD VM system where  a
    page gets marked as dirty,  but the underlying pages are  hardware
    protected against write, so the same contents are written out.

SOLUTION

    This is a well known bug in the FreeBSD VM layer.  The contents of
    the file do not  change.  You should  have md5 checksums of  files
    that you are concerned about.

    The fix for this problem  has been in FreeBSD-current since  April
    1997  and  is  now  merged  into  the FreeBSD-stable branch.  That
    means, it is  in all active  branches and will  be in the  3.0 and
    2.2.8 releases.