[zeromq-dev] ZMTP security

[Matthew Hawn]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mitm_test.py
Type: text/x-python
Size: 5495 bytes
Desc: mitm_test.py
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140919/48083900/attachment.py>