[zeromq-dev] Vulnerability of devices to incoming messages

Brian Granger ellisonbg at gmail.com
Wed Aug 11 23:34:55 CEST 2010


On Wed, Aug 11, 2010 at 11:23 AM, MinRK <benjaminrk at gmail.com> 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 think that XREP should raise an errno in situations like this rather than
it going silent.


> 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?
>
>
I guess that does match better.  But is that what we want?  I almost think
that both cases should raise an errno if the send fails.  Silent errors are
bad.

Brian


> -MinRK
>
> On Wed, Aug 11, 2010 at 04:03, Pieter Hintjens <ph at 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 <benjaminrk at 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 <ph at 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 <benjaminrk at 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 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
>
>


-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100811/8f3b9f43/attachment.htm>


More information about the zeromq-dev mailing list