[zeromq-dev] Vulnerability of devices to incoming messages

[MinRK]

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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100811/cbe46194/attachment.htm>