Bug 236306

Summary:	md5sum on important bin files not equal on different machines
Product:	[Fedora] Fedora	Reporter:	Denis Tumpic <dtumpic>
Component:	binutils	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6	CC:	security-response-team
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-04-12 23:29:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Denis Tumpic 2007-04-12 23:21:22 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070313 Fedora/1.5.0.10-5.fc6 Firefox/1.5.0.10

Description of problem:
when doing a md5sum /sbin/sulogin it will most likely echo different hash sums for each machine even if it is on the same architecture (i386 in my case.)

I had a slight HD problem and thought it would be a good idea to md5sum all bin and lib to check if there were more errors on other files.

HD problem machine:
2012ee3d1392e3d3a1e54ed208dec755 sulogin

Working machine without any problem:
3ccf82825c23abb4ba3fce2e55946579 sulogin

FC 6 Minimal clean install and not used (base line):
66b0cc2eb2837911eef67eb25b65896d sulogin

Using hexedit on the file it is apparent that the differences are in the same spots but they are all different variations so its not due to HD failiure.

Version-Release number of selected component (if applicable):
Same issue on RHEL 4 too as well as current FC6

How reproducible:
Always

Steps to Reproduce:
1. Choose a couple of machines with the same patch level and install
2. md5sum /sbin/sulogin
3. compare the result

Actual Results:
All my machines had different m5sums. I reproduced this on prior version of FC and RHEL.

Expected Results:
Well in a perfect world it would be identical or we should be able to know why it isn't identical (like fundamental gcc setting differences causing breakage... like gaim/pydgin not working properly although the code is correct.)

Additional info:
This is not necessarily a bug BUT it makes auditing a system a completely futile endeavor.

Comment 1 Josh Bressers 2007-04-12 23:29:59 UTC

This is the result of prelink adding randomization to the binaries.  I suggest
you see this Wikipedia article:
http://en.wikipedia.org/wiki/Prelinking

I suggest you rely on rpm -K to verify file integrity.

Comment 2 Denis Tumpic 2007-04-13 00:14:41 UTC

Thanks about the prelink explanation. But rpm -K works only at install time and
I am using that. However I need to know binary integrity long after the install
and specifically after I encounter problems or if machine is allegedly compromised.

Comment 3 Josh Bressers 2007-04-13 00:36:04 UTC

I'm sorry, I meant rpm -V, not -K.  -V is verify, it can show you differences
between the rpm database and the filesystem.

Comment 4 Denis Tumpic 2007-04-13 00:56:22 UTC

Doh! Yeah that definitely does exactly what I want. Thank you and sorry for
using bugzilla in this case.