His query is related to Growl as well as gfw, since both will use gntp
On Apr 15, 2010, at 12:39 AM, Carey Bishop <[email protected]>
wrote:
As your queries are related to Growl for Window, it would probably
be best to send them to the Growl for Windows Group:
Email: [email protected]
Online: http://groups.google.com/group/growl-for-windows
In theory, the purpose of the salt of is to prevent replay attacks,
so I believe that the Growl for Windows application should reject
messages that use the same salt, but I know from experience that it
currently does not.
Carey
On Thu, Apr 15, 2010 at 4:10 PM, Patrick Stein <[email protected]> wrote:
In the binary Growl Talk protocol, authentication was done by
computing a hash value for the whole message + a secret password
and appending this hash to the message. If someone could eavesdrop
on the Growl Talk communication, they could replay messages at
a later date without having to know the secret password. However,
they could not craft new messages for an application without knowing
the secret password.
I'm reading the GNTP spec here:
http://www.growlforwindows.com/gfw/help/gntp.aspx
and looking at this sample implementation here:
http://github.com/mattn/perl-Growl-GNTP/blob/master/lib/Growl/GNTP.pm
(which looks reasonably to spec except that it doesn't support
the x-growl-resource:// referencing)
And, it looks to me like the authentication got thrown out
inadvertently (in both the protocol spec and the sample Perl
code there). It looks like now anyone who can eavesdrop on
an encrypted or authenticated channel can both resend messages
at later times *and* craft new authenticated messages from scratch
without having to know the secret password.
Here's all that I have to do:
1. intercept a message
2. copy out the keyHashAlgorithm, keyHash, and salt.
3. craft any unencrypted message that I want using the same
keyHashAlgorithm, keyHash, and salt
GNTP/1.0 NOTIFY NONE keyHashAlgorithm:keyHash.salt
<any message that I desire>
This new message will have a valid keyHash since the keyHash
did not depend on the message contents in any way. The only
way this might still be okay is if the server side keeps track
of every keyHash/salt it has ever received and only lets each
get used once. This would be a nightmare on both ends of the
socket.
The situation looks to be even worse in the sample Perl code
that I was looking at because it appears (and, maybe I am reading
it incorrectly, but it appears) step #5 is omitted from the
Key Generation described in the protocol document and the actual
key itself is sent in place of the keyHash. This means that I
can even send encrypted (and authenticated) messages without
ever needing to know the password since I already have the
encryption key in my hand. I hope the server side is not skipping
step #5 and will reject all of the encrypted messages generated
by that Perl code.
Can somebody please clarify?
Even if we don't bother correcting the protocol to prevent
replays, we should at least make sure you cannot send arbitrary
authenticated (or encrypted!!) messages without the secret
password.
Thanks,
Patrick
--
You received this message because you are subscribed to the Google
Groups "Growl Discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected]
.
For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en
.
--
You received this message because you are subscribed to the Google
Groups "Growl Discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected]
.
For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en
.
--
You received this message because you are subscribed to the Google Groups "Growl
Discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/growldiscuss?hl=en.
