GNTP Authentication/Encryption Problem/Question/Query

[Patrick Stein]

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

[Patrick Stein]

It seems to me that the reason each binary item is encrypted
separately is so that "The server MAY choose to use a cached
copy of data with the same uniqueid..." and "...interrupt packets
before they are fully received if all uncached data has been
received."

I understand the idea here, but it seems to me like it could cause
a deadlock situation (especially sending to localhost) where the
client sends some huge amount of data that the server has seen
before. The server decides not to keep reading the data from the
client and just writes the response. The client, however, gets
blocked trying to write the data that isn't being read and never
makes it to the point of reading the response.

Admittedly, you'd have to be sending quite a bit of data. But, if
you are for some reason, you'd need some super-careful client side
code to dodge the deadlock. You'd either need non-blocking I/O
set on the socket or you'd have to select(2) before each write(2)
whether the other side is ready for more data (and then you'd still
have to send your data in small chunks at a time).

Alright, bedtime for me,
Patrick

[Carey Bishop]

As your queries are related to Growl for Window, it would probably be best to send them to the Growl for Windows Group:

Email: growl-fo...@googlegroups.com

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

--
You received this message because you are subscribed to the Google Groups "Growl Discuss" group.
To post to this group, send email to growld...@googlegroups.com.
To unsubscribe from this group, send email to growldiscuss...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en.

[Chris Forsythe]

His query is related to Growl as well as  gfw, since both will use gntp

[Patrick Stein]

On Apr 15, 2010, at 12:39 AM, Carey Bishop 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: growl-fo...@googlegroups.com

Online: http://groups.google.com/group/growl-for-windows

My queries are related to GNTP, which Growl for Mac is moving

toward using, too.  I hadn't realized until an hour after my first

message that the Growl for Windows is already fairly far along

and has a ton of clients already.

That's unfortunate, because this looks like a system crypto

problem that will require significant rework of the protocol

to overcome.

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.

I don't believe that is what salt is supposed to be for.  Salt is

supposed to make it harder to do some sorts of cryptanalysis.

Actually, I believe the way salt is used in GNTP, it actually hurts

the cryptographic strength to use a different salt every time.

Typically, when you an encrypt the password "foobie", you encrypt

it with some random salt.  Then, when you're looking down through

a list of passwords, you can't readily see that two different people

used "foobie" as a password because they both used different salts.

It defeats the purpose of the salt if everyone knows that

xxABCDEFG and yyMNOPQRS are both the same password just

encrypted with different salts.

The way that most systems prevent replay attacks is something

like this:

    h := hash( salt + timestamp + my-ip-address + my-socket-port + password );

    transmit( salt, timestamp, my-ip-address, my-socket-port, h, message );

The receiving end verifies that the ip-address and port jive with where

the message was received from, the timestamp isn't too far in

the past or future (have to give a bit of grace here because no

two computers agree on the time, plus there is network latency),

and the hash works out.  Of course, NAT firewalls make the port

kinda and IP address kinda awkward for the sender to figure out.

But, just the timestamp is a decent start.

Note: this doesn't prevent someone who can quickly grab the same

ip-address and socket-port from sending the same message or

composing an entirely different message unless the server side

rejects repeated salts.  But, tracking which salts have already been

used is a bookkeeping headache for both sides.  This is especially

a headache for a client like a command-line tool to send a message.

Such a tool would start up, send one single message, and exit.  It

could do this several times per second.  It probably wouldn't get the

same port each time, but it would have the same IP address and

timestamp (though hopefully different salts, unless the salt is done

with the typical srandom( time( NULL ) ) or without even using

srandom() at all).

I love Growl for Mac and Growl Talk.  I thought GNTP was a bit

overblown on verbiage, but was fine with it until I started to try

to deal with the authentication and encryption portions.  Now, I

don't want to have to do GNTP at all unless some of the crypto

troubles get addressed.

So, I suppose my questions below have now become more like:

   * Does the encryption in the Perl library I link to below

       actually succeed in publishing encrypted messages?  If so,

       then, I think the server's got an encryption bug that leaves

       it worse off than even the Protocol document indicates it would be.

   * Are these the proper fora for discussing this issue?

   * Should I prepare a new rev of the GNTP protocol spec

       that I think uses crypto better than the 1.0 spec and

       send it around for discussion?

Briefly, the main GNTP/1.X line should have a hash algorithm,

salt, and hash of:

      main (encrypted or not) message header bytes + salt + password

Each binary object should have (in addition to the Identifier and Length)

a hash algorithm (or assert the same hash algorithm everywhere),

salt, and a hash of:

       (encrypted or not) binary data + salt + password

Alternately, to take advantage of the fact that the Identifier may already

be a hashed value, the new binary object header should have a hash of:

        hash( (encrypted or not) binary data ) + salt + password

Thanks,

Patrick

[briandunnington]

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.

[Patrick Stein]

On Apr 15, 2010, at 10:43 AM, Brian Dunnington <briandu...@gmail.com
> wrote:

> replay attacks are
> possible and were a known compromise in deciding on the current
> system.

I don't think it's really necessary to fight off replay attacks.
Someone mischievous could keep resend a message over and over, but it
shouldn't be hard to deal with such persons in meatspace. ;)

> your main point though about being able to intercept the keyhash.salt
> and re-use it is valid. i would love to come up with a workable
> solution that the Mac guys can implement as well.

In the Growl Talk protocol, authentication worked fine. All it would
take on GNTP is rather than sending the password hash sending the hash
of the body + password.

-- Patrick <p...@nklein.com>

[Peter Hosey]

On Apr 14, 2010, at 21:10:31, Patrick Stein wrote:
> And, it looks to me like the authentication got thrown out inadvertently (in both the protocol spec and the sample Perl code there).

Yeah, GNTP is a complete reboot. We started with some problems we wanted the protocol to solve, and started afresh on those problems, rather than looking at the existing UDP protocol and trying to upgrade it.

Security is pretty much the last thing we looked at, and we never finished it. Thanks for reviving that discussion—GNTP will be stronger for it.

[briandunnington]

On Apr 15, 8:58 am, Patrick Stein <p...@nklein.com> wrote:
> On Apr 15, 2010, at 10:43 AM, Brian Dunnington <briandunning...@gmail.com

>
>  > wrote:
> > replay attacks are
> > possible and were a known compromise in deciding on the current
> > system.
>
> I don't think it's really necessary to fight off replay attacks.  
> Someone mischievous could keep resend a message over and over, but it  
> shouldn't be hard to deal with such persons in meatspace.  ;)

agreed 100%

> > your main point though about being able to intercept the keyhash.salt
> > and re-use it is valid. i would love to come up with a workable
> > solution that the Mac guys can implement as well.
>
> In the Growl Talk protocol, authentication worked fine.  All it would  
> take on GNTP is rather than sending the password hash sending the hash  
> of the body + password.

i was worried that we would risk getting into a chicken-and-egg
situation with encrypted requests (you need the key to encrypt the
message body, but you need the encrypted body to generate the key
hash), but that isnt true.

the *key* is generated in step #4 and can then be used to encrypt the
message. once that is done, the *key hash* (generated in step 5) could
be generated. (i am assuming that the key hash is using the password +
encrypted body so that the receiver doesnt have to first try to
decrypt the body with a potentially invalid key).

that would also mean that 'body' means each individually-encrypted
section (so that binary resources are still encrypted separately). for
binary sections, we have a few options:

1. add new header(s) to indicate the section hash, hash algorithm, and
salt
2. add new header(s) to indicate the section hash and salt (require
and assume the same algorithm as the main body)
3. add new header(s) to indicate the section hash (require and assume
the same algorithm and salt as the main body)
4. no changes (require and assume the same algorithm and salt as the
main body, as now)

#4 would mean that an attacker could intercept a message and, although
they could not modify the main body or the number of binary resources,
they could swap out a binary resource for a different one. if that is
unacceptable, i would think #3 would be sufficient. the salt is still
serving its purpose even if it is reused for binary items in the same
message (in fact, that is how the IV is currently used). i think that
#1 is probably overkill, since i cant think of anyone (or any reason)
why you would want/need to use a different algorithm for each section.

i know that Mac support is still nascent, but i would really like to
see these encryption changes labeled as GNTP/1.1. there are a lot of
client libraries already written to the current 1.0 spec and it would
be nice to be able to transition to the new spec without having them
all break overnight when the receiver is updated.

[Patrick Stein]

On Apr 15, 2010, at 2:12 PM, briandunnington wrote:

> 1. add new header(s) to indicate the section hash, hash algorithm, and
> salt
> 2. add new header(s) to indicate the section hash and salt (require
> and assume the same algorithm as the main body)
> 3. add new header(s) to indicate the section hash (require and assume
> the same algorithm and salt as the main body)
> 4. no changes (require and assume the same algorithm and salt as the
> main body, as now)

I think #3 is fine. I'm not keen on #4 because of the swapping out
possibility. It's probably not a huge worry, but most code would
probably have to have some generic way to encrypt a block of data
anyhow.

The only reason that I could see preferring #1 to #3 is that the client
could have prepared the binary resources ahead of time and used them
even though the header of the message uses a different salt and hash.
But, that, again, allows someone to mix and match binary resources
from across messages. So, yep... I'm back to #3 (or #2, but I don't see
a real advantage to #2 unless MD5 is loads faster than SHA256 on
your machine).

> i know that Mac support is still nascent, but i would really like to
> see these encryption changes labeled as GNTP/1.1. there are a lot of
> client libraries already written to the current 1.0 spec and it would
> be nice to be able to transition to the new spec without having them
> all break overnight when the receiver is updated.

*nod* That definitely should happen, IMBBO.

alter,
Patrick

ps. Just successfully got my Lisp code to REGISTER with Growl-for-Windows
with the MD5 password-hashing but no encryption yet.... (and, I just realized
that the way that I have the encryption organized at the moment is wrong
since I'm not encrypting each block of binary data yet, but that's easy to fix).

[Chris Forsythe]

On Apr 15, 2010, at 2:12 PM, briandunnington
<briandu...@gmail.com> wrote:

I'm fine with that. Using your implementation and the other libraries
to get it right is definitely the right way to do things since we have
the opportunity to do so.

Chris

[Peter Hosey]

On Apr 15, 2010, at 12:12:05, briandunnington wrote:
> i know that Mac support is still nascent, but i would really like to see these encryption changes labeled as GNTP/1.1.

I would say 1.0.1, since this doesn't add any new capabilities.