[zeromq-dev] Vulnerability of devices to incoming messages

Wed Aug 11 23:37:37 CEST 2010

On Wed, Aug 11, 2010 at 12:02 PM, Matt Weinstein
<matt_weinstein at yahoo.com>wrote:

>
> On Aug 11, 2010, at 2:52 PM, MinRK wrote:
>
>
>
> On Wed, Aug 11, 2010 at 11:37, 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.
>>
>
> The issue is that the builtin devices forward messages without checking.
> The only checking happens on the client side, and that only checks whether
> it is a valid message sent to the input socket, not that the message will be
> valid on its way out of the output socket.
>
>
> You could implement a device with error checking using zmq_reactor.  Just a
> thought, and not a bad one.
>
> My code doesn't ever cause the error, but all a malicious code needs is
> access to the non-XREP port, and they can trivially crash the entire process
> containing the device, and there's nothing my code can do about it short of
> protecting the port itself.
>
>
>
> Yes, do this.  Preferably by moving it to a VLAN or other network segment
> that is protected.  And use a startup handshake to prevent port probes from
> blowing you up.
>
>
The problem is that the app Min is developing is deployed by ours users who
are often not sys admins.

>
>> Making the traffic disappear without any indication will make error
>> detection and correction much more difficult, especially when dealing with
>> these exotic socket types.
>>
>
> I agree that debugging your XREP code will be more difficult if you do
> this, but that's already tricky, since if you have a wrong IDENT, your
> messages silently vanish already.
>
>
>
> Actually, they're with the other sock that disappears from the dryer :-)
>
>
>> 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.
>>
>
> Returning an error code rather than raising SIGABRT is a good model.  That
> allows prudent* user code with an XREP socket to notice the error, but
> protects the devices from this vulnerability, as long as they don't have
> 'assert(rc!=0);' code, which they currently do.
>
>
> IMO, both XREP and XREQ should return errors on failure to find the right
> pipe, but the problem is there may be race conditions where you get spurious
> errors?  Also, I'm not sure if the ypipe selectors needed for this are
> available locally, I haven't looked ...
>
> *by prudent, I mean the traditional:
> rc = xrep.send(msg);
> if (rc != 0){
>    handle_it();
> }
>
>
>>
>> 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 <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
>>
>>
>>
>> _______________________________________________
>> 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/fa49f719/attachment.htm>