Re: su doesn't work "Authentication failure"
"Dennis G. Wicks" <email@example.com> writes:
> Kevin Buhr wrote the following on 01/31/2008 12:50 PM:
> From aptitude show login ==>> 1:18.104.22.168-7 <<==
>> should give:
>> 1381ae1ac77b512258657b096522bb6a /bin/su
> c80fc747e24fa8bfa099cbef0bfb926f /bin/su <<==
> from md5sum /bin/su
>> If your Etch version matches mine but the md5 doesn't, you might start
>> to get pretty worried.
Dennis, I posted a followup message but you might have missed it. I
was sloppy: the 1381... hash I posted was for the amd64 architecture;
the c80f... hash you list matches what should be expected for i386, so
there's no problem with your copy of "/bin/su".
> What should I be worried about and start looking for?
Since yours *does* match, you don't have any worries.
More generally, though, in the normal course of events, files (other
than configuration files and the like) installed on your system should
match the version in the appropriate Debian package. A hash mismatch
just means the files don't match. There are many possible
explanations for this, most of them innocent:
1. First, as we encountered above, the package version, architecture,
or official source of the package might not match precisely.
When I say "official source", the main Debian archive and any of
its mirrors would be considered a single source, so all should
have precisely matching packages. On the other hand, if you
install packages you've compiled from source or gotten from a
"backports" site or from a derivative distribution (Ubuntu, etc.),
a mismatch is likely occur even with a perfect
2. The file might be a "special" file that gets modified on
installation. Configuration files in "/etc" for example will
frequently differ from the source, even when a package is freshly
3. The file might have been intentionally modified by the system
4. The file might have become corrupted.
5. The file might have been installed from original installation
media whose copy didn't precisely match the file in the official
package and no later version of the package has ever been
6. The file might have been tampered with by someone who broke into
7. You may have somehow been tricked into installing a malicious
version of the package.
These are probably in roughly the order of likelihood, so I should
have tried harder not to sound alarmist, since the ones to worry about
are way down at the bottom of the list.
For "/bin/su", a mismatch is cause for immediate suspicion (especially
if, as seemed to be the case for the original poster, something weird
is going on with that file anyway) simply because it's a
security-sensitive utility that is a frequent target for rootkits and
Kevin Buhr <firstname.lastname@example.org>