[zeromq-dev] ZMTP security

[Pieter Hintjens]

Thanks for confirming this, Matthew.

On Fri, Sep 19, 2014 at 10:36 PM, Matthew Hawn
<matthewh at donaanacounty.org> wrote:
> I can confirm that fe4396c597929382214c7966e60f025114d4f32d fixes the issue.
>
> I ran test the script against the two commits:
> 8e9005d59197306d1033c70eeba3322474c3b097
> This commit is still vulnerable and downgrade is possible
>
> fe4396c597929382214c7966e60f025114d4f32d
> This commit is not vulnerable.  Client and server both immediately close the connection on detection of invalid mechanism.
>
>
>
> ________________________________________
> From: zeromq-dev-bounces at lists.zeromq.org [zeromq-dev-bounces at lists.zeromq.org] on behalf of Matthew Hawn [matthewh at donaanacounty.org]
> Sent: Friday, September 19, 2014 1:18 PM
> To: ZeroMQ development list
> Subject: Re: [zeromq-dev] ZMTP security
>
> I should be able to test later this afternoon and let you know.  I almost have the C test case and should have that soon as well.
> ________________________________________
> From: zeromq-dev-bounces at lists.zeromq.org [zeromq-dev-bounces at lists.zeromq.org] on behalf of Pieter Hintjens [ph at imatix.com]
> Sent: Friday, September 19, 2014 11:29 AM
> To: ZeroMQ development list
> Subject: Re: [zeromq-dev] ZMTP security
>
> Matthew,
>
> Thanks for insisting. Of course your first email was correct. In the
> test case I made, the downgrade actually happens, except the client
> also suffers an upgrade, so the handshake fails (as expected) for the
> wrong reasons.
>
> I've sent a pull request with a simple patch that does as you suggest,
> to check the mechanism selected in the options, before continuing.
> Attempting a downgrade should cause the connection to be rejected.
>
> Would you be able to retest your case against libzmq master once this
> patch is merged?
>
> https://github.com/zeromq/libzmq/pull/1188
>
> -Pieter
>
> On Fri, Sep 19, 2014 at 7:14 PM, Pieter Hintjens <ph at imatix.com> wrote:
>> Matthew,
>>
>> For the benefit of others I'm posting the MIM Python program you sent me.
>>
>> This seems to (I am too stupid to install pyzmq, so can't run it)
>> prove the downgrade attack; it forces both client and server to NULL
>> and then captures the traffic.
>>
>> -Pieter
>>
>> On Fri, Sep 19, 2014 at 9:36 AM, Pieter Hintjens <ph at imatix.com> wrote:
>>> So you can downgrade the client by ignoring the mechanism it sends,
>>> and accepting the connection without any further verification? That is
>>> worth fixing, yes.
>>>
>>> Could you perhaps add that test case to the libzmq test cases?
>>>
>>> I don't think you can downgrade the server to null however, can you?
>>>
>>>
>>>
>>> On Fri, Sep 19, 2014 at 12:55 AM, Matthew Hawn
>>> <matthewh at donaanacounty.org> wrote:
>>>> I was thinking more of a malicious man-in-the-middle.  I have a test case available that downgrades curve to null.
>>>> ________________________________________
>>>> From: zeromq-dev-bounces at lists.zeromq.org [zeromq-dev-bounces at lists.zeromq.org] on behalf of Pieter Hintjens [ph at imatix.com]
>>>> Sent: Wednesday, September 17, 2014 11:33 PM
>>>> To: ZeroMQ development list
>>>> Subject: Re: [zeromq-dev] ZMTP security
>>>>
>>>> I just added a test case to test_security_curve where the client tries
>>>> to connect to a server socket configured with CURVE, while using a
>>>> NULL mechanism. This is what libzmq logs:
>>>>
>>>>     NULL I: client sent invalid NULL handshake (not READY)
>>>>
>>>> And it does reject the connection. So that seems to work properly.
>>>> Same thing when I try to use a PLAIN user/password.
>>>>
>>>> -Pieter
>>>>
>>>> On Wed, Sep 17, 2014 at 11:52 PM, Matthew Hawn
>>>> <matthewh at donaanacounty.org> wrote:
>>>>> I think I might have found a problem with negotiation of the security mechanism. In the current source,   zmq::stream_engine_t::handshake sets up the security mechanism based on the greeting received from the peer, but does not seem to validate that against what was sent to the peer or specified in the socket options.  Am I missing something?
>>>>>
>>>>> Matt
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> zeromq-dev mailing list
>>>>> zeromq-dev at lists.zeromq.org
>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>> _______________________________________________
>>>> zeromq-dev mailing list
>>>> zeromq-dev at lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>
>>>> _______________________________________________
>>>> zeromq-dev mailing list
>>>> zeromq-dev at lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>