PREVIEW: bsign embeds hash and/or digital signature in ELF files

Oscar Levi elf at buici.com
Tue Dec 15 02:28:49 CET 1998


On Mon, Dec 14, 1998 at 06:08:30PM -0500, Stainless Steel Rat wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> "OL" == Oscar Levi <elf at buici.com> writes:
> 
> OL> And how is this better?
> 
> For one, it works regardless of file type.  The method of embedding
> signatures in the file cannot be used for the numerous text and flat files
> on a Unix system, such as password/shadow and almost everything else in /etc.

There is no expectation that bsign will work for generic text files.
I have amother idea for them.

> For another, assuming someone manages to break into your system and learns
> about the trick you are utilizing, it is relatively easy for him to add a
> valid signature for his trojan version of whatever he installs on the
> system.  When you go to check the signature, it will validate just fine,
> and you will not be able to tell otherwise since the signature you
> generated and the file it was generated against is gone.

This is true of any algorithm.  If the tripwire database were writable
on the harddrive, it would be vulnerable the same way.  The big
difference here is that tripwire requires that the whole database be
read-only and remain intact.  Loss or unavailability of the database
means there is no way to tell if the system has been tampered.  With
embedding, the only thing to keep safe is the public/private key pair.
This can be put on a floppy that is read-only and never has to change.
Most people's public keys are available on the internet, so absence of
the public key from it's expected spot is recoverable.  If the SA
loses his private key then he probably has more important things to
worry about than tampering with his system. 

> 
> If you keep your signature database on read-only media, such as a
> write-protected floppy disk, it is impossible for this to occour.  

Except that the SA must make the floppy writable when updating the
database and remember to make it read-only when the db update is
complete. 

> And there are few Linux/GNU systems that do not have a working /dev/fd0.

What do you intend to say here?

Mr. Rat, I think I understand your point of view on this.  I have
received similar comments from several people.  Given that bsign will
never sign any file type, no one has been able to explain why they are
so upset.  Tripwire is more complex than bsign and, therefore, has
more failure modes.  It adds a step to normal SA, updating the
database on it's read-only medium, that I feel is undesirable and
unnecessary.  

If a system never changes, then tripwire is a perfect fit.  None of
the systems I administer are static.  Moreover, I am very likely to
perform the administration remotely where I don't have access to the
floppy.  I can, however, sign files by transfering them to my local
machine where I have access to a safe copy of my key.  I can leave a
read-only floppy in the drive with my public key, or I can verify the
signatures remotely using a script, the same script I run on every
machine I administer.

Cheers.




More information about the Gnupg-devel mailing list