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.
Making the traffic disappear without any indication will make error
detection and correction much more difficult, especially when dealing
with these exotic socket types.
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.
Thanks,
Best,
Matt
On Aug 11, 2010, at 2:23 PM, MinRK wrote:
That does indeed fix the vulnerability in my code, thanks!
Is it better for zmq in general, though, for xrep.send('msg') to
silently fail, rather than raise? It's good for me, but I can
imagine others having objections.
I suppose this does better match the behavior of having an unmatched
identity prefix on a valid message on an xrep, which just vanishes
into the aether, right?
-MinRK
On Wed, Aug 11, 2010 at 04:03, Pieter Hintjens <p...@imatix.com> wrote:
Hi Benjamin,
Here's a patch for xrep.cpp that silently drops the message if it's
malformed. This will make the standard devices robust against the
vulnerability you explained.
I've tested it and it works for your test case. Could you confirm it
works, then I'll commit the change to master.
http://gist.github.com/518810
-Pieter
On Tue, Aug 10, 2010 at 7:30 PM, MinRK <benjami...@gmail.com> wrote:
> It is posted here:
> http://github.com/zeromq/zeromq2/issues/issue/46
> with accompanying gist for reproducing the issue.
>
> -MinRK
> On Tue, Aug 10, 2010 at 01:25, Pieter Hintjens <p...@imatix.com>
wrote:
>>
>> Benjamin,
>>
>> Could you provide a minimal test case that reproduces the
problem, and
>> perhaps file an issue on the github tracker, thanks.
>>
>> -Pieter
>>
>> On Tue, Aug 10, 2010 at 8:34 AM, MinRK <benjami...@gmail.com>
wrote:
>> > Hello,
>> > I'm using ZMQ devices for parallel computing in IPython. One
of our
>> > devices
>> > is a Queue with XREQ on one side and XREP on the other. This
model, like
>> > any
>> > device where one socket requires an IDENT prefix (XREP), and
the other
>> > does
>> > not prepend a message (anything other than XREP), is vulnerable
to
>> > invalid
>> > messages. If the socket that is not XREP receives a single
message, that
>> > will be relayed to the XREP as a message with routing IDENTITY
but no
>> > content. This fails an assertion, and triggers SIGABRT,
bringing down
>> > the
>> > entire process.
>> > It is a security concern for us that _incoming_ messages have the
>> > ability to
>> > crash the device process. Are there any standard models or
plans for ZMQ
>> > devices that can survive invalid messages like this?
>> > -MinRK
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev@lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> >
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
