[zeromq-dev] Vulnerability of devices to incoming messages
matt_weinstein at yahoo.com
Wed Aug 11 20:51:47 CEST 2010
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
That's why the assertion fails, it reads (virtually) ==>
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).
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
>> destruction within the environment.
> OK, I'll leave the branch open until we get consensus on this.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev