Darren New wrote:
> In terms of having better date stamps, tracking of which hosts the
> message had been relayed through, etc, syslog-reliable/cooked is
> designed to do that flexibly and informatively and still in a way
> compatible with syslog-signed. I.e., it adds all that information
> without actually changing the body of the message, so signatures don't
> get corrupted and so on.
There is an inherent security flaw in that. Information that can be added
without invalidating the signature is also information that is not protected
by the signature, and can be changed with impunity.
For example, if you produce an entry like this:
<entry hostname="foo.bar.com" etc.... >
... syslog-signed message, unchanged, including hostname etc...
</entry>
You now have 'hostname' expressed twice - but one is involved in the
signature and the other isn't. That means they need not be the same. That's
a potential security problem for any processor that is relying on the one
that isn't signed, i.e the attribute version.
Same goes for any other attribute of 'entry'. For example a rogue relay
meddling with 'facility', 'severity', or 'tag' might be able to redirect a
lot of urgent messages to /dev/null - effectively deleting messages without
tripping the signature mechanism.
On the other hand, if you do this:
<entry hostname="foo.bar.com" etc ...>
..syslog-signed message, changed to remove hostname and other parsed
attributes...
</entry>
Now nothing is redundantly expressed and you have to reconstruct the
canonical syslog-signed message before you can validate the signature. This
is a bit more work but you can now trust the parsed attributes because they
are properly involved in the signature validation.
Unfortunately in either case it's difficult to add additional attributes
that are parsed from the payload, and trust them - it may be better (in the
case where the device is also using syslog-reliable cooked), to compute the
signature over a canonical XML form of "<entry ...> .... </entry>", i.e.
consider the whole entry to be the raw syslog message.
Cheers,
Frank
