[zeromq-dev] Vulnerability of devices to incoming messages

[Matt Weinstein]

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.

>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100811/73b27ae1/attachment.htm>