[zeromq-dev] Vulnerability of devices to incoming messages
MinRK
benjaminrk at gmail.com
Tue Aug 10 20:20:59 CEST 2010
On Tue, Aug 10, 2010 at 10:14, Pieter Hintjens <ph at imatix.com> wrote:
> Hi Benjamin,
>
> Thanks for posting the test case, it makes it clear.
>
> At the least the documentation for zmq_device(3) should state what
> socket types are safe to use. Do any other socket types prepend an
> identity apart from XREP?
>
Not that I know of - it seems that it's only XREP that requires/adds a
prefix. That means that a device with an outgoing XREP is only safe from
this if the incoming socket is also XREP. This introduces the new problem
that the IDENT added as a prefix by the receiving XREP is used for routing
on the outgoing XREP. So, while it is safe from this vulnerability, it's not
especially useful. So I guess that XREP can't safely be used as an
*outgoing* socket in regular devices at all.
I use exactly this model (XREP/XREP Queue) in one of our devices, and added
a simple mechanism for swapping the incoming IDs.
Note that the vulnerability is not a problem in devices where the XREP
socket only receives, such as the incoming socket on a Forwarder.
-MinRK
>
> -Pieter
>
> On Tue, Aug 10, 2010 at 10:25 AM, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100810/416c70de/attachment.htm>
More information about the zeromq-dev
mailing list