if the Perl library is indeed skipping step #5 when it is generating the key hash, then the server will definitely reject the request. i have not personally gone through every one of the current GNTP libraries to test every bit of functionality, but i do know that some are more compliant than others.
as Carey said, each unique salt is not tracked on the server side (in GfW). as such, it is still possible to do a replay attack using this scheme. we have had many discussions about GNTP security and in the end, the decision was made that the security should be important, but it wouldnt necessarily be bulletproof. i think it was Chris who said 'we are just talking about notifications, right?'. that said, i agree with you that replays are one thing, but being able to send arbitrary authenticated messages is another. there are several things we could do to correct that issue, but i will defer to Chris and Peter and the group to see what they would like to do. On Apr 14, 9: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.
