Plugin to check MD5 sum on certain files

[Andreas Ericsson]

First off, I'm on the list. There's no need to send me two additional 
copies with each reply that goes to the list.

With that out of the way, answers below.

Dan Stromberg wrote:
> On Sat, 2004-11-06 at 05:03, Andreas Ericsson wrote:
> 
> 
>>>I believe this would be difficult - generating a trojaned ls with the
>>>same md5 sum.  md5 is designed to distribute small bits of a file, from
>>>all over within that file, across different parts of the digest.
>>>
>>
>>You're attacking the wrong end of the problem. If someone can trojan 
>>some of your binaries, they can trojan ALL your binaries (assuming 
>>you're not a complete idiot who have given write permissions away on 
>>some of your $PATH directories to non-root users).
> 
> 
> Trojaning binaries in a read-only, NFS mounted volume is possible, but
> difficult.
> 

No, it's simple. It's merely an exercise of replacing a few more 
binaries and then remount that same part of the system using a local 
filesystem. It's security by (not very) obscurity: Useless.

> Alternatively, or additionally, you can NFS mount the filesystem you
> intend to check and run a trusted md5 and sha-1 generator on a trusted
> system.
> 

It fails for the reasons stated above.

> 
>>A trojaned md5sum program would not report the proper md5sum, but rather 
>>some hardcoded value which the attacker retrieves from the 'real' ls and 
>>compiles in to the new md5sum program. If you can't trust one root-owned 
>>mode 755 binary, you can't trust any other either. It's as simple as that.
> 
> 
> Clearly.
> 
> 
>>>It's not like you can just assume a one to one mapping, or tack some
>>>crud on the end.
>>
>>I know perfectly well how md5 hashing works. I also know that what 
>>you're trying to implement is utterly useless unless you run everything 
>>off some non-writable media. It just won't work. Worse, it will create a 
>>false sense of security, so a possible attacker can hang on to your 
>>system for a much longer period once properly compromized.
> 
> 
> So why are we ruling out nonwritable media?  :)

I'm not. I'm ruling out MOUNTED read-only media, because it's not 
logically read-only if you already have access to replace system 
binaries. A root file-system on read-only media with network mounted 
untrusted writeable media would be secure though.

>  Granted, that's fakeable too, but like I said above, it's hard.

I can easily prove you wrong in two commands. Assume "fake-share" holds 
all binaries and files located on the real share, but trojaned when 
necessary.

umount /shared/disk/mount/point
mount <options> fake-share /shared/disk/mount/point

And we're done.

>  And we already had
> nonwritable media in the discussion anyway, so there's no point in
> arbitrarily ruling it out for one purpose and not another.
> 
> Please don't spin the "false sense of security" yarn again.  That's so
> overused.

Perhaps so, but still. The false security is why systems stay 
compromised, and why real security isn't applied. Idiot ideas by idiot 
admins is why script kiddies get cocky and stay "in business".

>  Better to light a candle in the darkness, than to complain
> that it isn't a floodlight and do nothing.  An effort doesn't have to be
> 100% effective to be valuable.
> 

Correct, but it should at least require more than two commands (and very 
trivial changes to a few extra standard programs) to be circumvented.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null