[zeromq-dev] Curvezmq Message Replay

[Pieter Hintjens]

The spec says,

> Note that the client uses an 8 octet "short nonce" in the HELLO, INITIATE, and MESSAGE commands. This nonce SHALL be unique in each command within a connection. The client SHALL NOT send more than 2^64-1 commands in one connection. The client MAY use any strategy to generate unique short nonces, including using an incremental counter.

And ditto for the server. The spec is somewhat confused about short
nonces in other places.

I removed the CurveCP aspects for using sequential numbers for long
term nonces, which I felt were complex and unnecessary, given a good
random number source.

So I see you sent a patch to check short nonces. That's helpful.
https://github.com/zeromq/libzmq/pull/1189

I'll tidy up the RFC 26 and merge that patch.

Then I'll backport these two fixes to zeromq4-x.

Thanks for these fixes.

-Pieter




On Sat, Sep 20, 2014 at 12:38 AM, Matthew Hawn
<matthewh at donaanacounty.org> wrote:
> It appears that messages within a session in zeromq can be replayed.  This does not happen across sessions, but within sessions. Here is a python script to confirm: https://gist.github.com/anonymous/d8b09c98de050dfbd1b4
>
> This can replay either client or server messages
>
> The problem is that the peer does not check the message nonce to detect replay.  Unfortunately,  because of the curvezmq spec, short nonces can potentially be any value. This makes it nearly impossible to track previously used nonces  This is because CurveZMQ specifically loosened the requirements for strictly incrementing short nonces.  The base protocol, CurveCP does require incrementing short nonces for both packet ordering and replay detection.
>
> On the plus side, both curve and libzmq use incrementing short nonces.  Some simple code to store and check against the last nonce received should be trivial and would not cause any interoperability problems with these two libraries.  This would completely solve the problem. However, the CurveZMQ spec would need to be changed to re-include the strictly incrementing short nonces.  Also, any other native libraries would need to ensure  compliance.
>
>
> This is only about the short nonces as part of the message packet.  Duplicating the other packets will break from the protocol and is easily detected and handled by the implementations.  The long nonces are used together with the transient keys and cannot be duplicated.   Codes-In-Chaos did mention a replay attack on client sessions.  libzmq and curve are not vulnerable as they both regenerate their cookie key for every connection and persist the server transient key between hello and initiate.
>
>
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev