Does the on-disk image of an executable ever change?

[Ben Scott]

On Wed, Nov 4, 2009 at 3:50 PM, Michael ODonnell
<michael.odonnell at comcast.net> wrote:
> I'm seeing differences in the on-disk images of things like /sbin/mount and
> /lib64/libblkid.so.1.0 that AFAIK are supposed to be entirely static.

  Use "rpm -qif /lib64/libblkid.so.1.0" to identify the exact package
owning the file, and compare version, release, epoch, and build date.
Sometimes you see "1.2.3" and think they're the same, but don't
realize it was actually "1.2.3" vs "1.2.3b" or whatever.

> WTF?  Is it ever the case that it's OK for the on-disk image of an
> executable to change once it's been laid down?

  I don't think so.

  There's that prelinking thing that RPM sometimes complains about,
but I don't think that writes to the binaries themselves.

  One possible cause is system compromise followed by the attacker
replacing executables.

> Also, since the systems in question don't have their RPMs handy I wonder
> if there's some simple trick that would allow me to automagically verify
> the various files against their corresponding RPMs in some repository
> out on the Net without having to explicitly drag them all onboard and
> execute an "rpm --verify" by hand...

  Just execute "rpm --verify --all", and RPM will verify every file in
every package installed on the system.  It doesn't need the original
RPMs you installed from, and it won't use them even if you have them.
It uses the RPM database (/var/lib/rpm/), which normally contains
details about everything.  It will check date, time, size, mode,
owner, MD5 checksum, and maybe some other stuff I forgot.

  "rpm --verify all" is quite possibly the thing I like best about Red
Hat Linux vs every other OS.

-- Ben