[zeromq-dev] Vulnerability of devices to incoming messages

[Matt Weinstein]

Thanks.

Either the DEVICE (or an equivalent intermediary), or the process at  
the other end of the PAIR (or both) should be checking the message  
formats, and more likely should have only been constructing valid  
messages sequences.

That's why the assertion fails, it reads (virtually) ==>  
assert(your_msg_sequence_properly_constructed)

Also IMO it's a bit early to be dropping the shields, we still don't  
know who the is enemy yet.

If they need to replace the device with one that does more error  
checking zmq_reactor will suffice (samples/queue).

Best,

Matt

On Aug 11, 2010, at 2:41 PM, Pieter Hintjens wrote:

> On Wed, Aug 11, 2010 at 8:37 PM, Matt Weinstein
> <matt_weinstein at yahoo.com> wrote:
>
>> Here's one argument against this:
>> If you forward a malformed stream to an XREP you have a design  
>> flaw, and you
>> should fix it.  Proper input checking should be done.
>
> This is a good point.  The standard devices could check their input
> before sending it on.  However they don't know the type of the backend
> socket, do they?  So they can't determine whether it needs a multipart
> message or not.  Sorry if I'm not getting this right...
>
>> Making the traffic disappear without any indication will make error
>> detection and correction much more difficult, especially when  
>> dealing with
>> these exotic socket types.
>
> Indeed.  Silently dropping the message seems wrong.
>
>> If you do decide to implement the non-strict form, it is still an  
>> error IMO
>> and should return an error indication, even if it does not cause  
>> massive
>> destruction within the environment.
>
> OK, I'll leave the branch open until we get consensus on this.
>
> Thanks
> Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev