[zeromq-dev] Curve: Potential DoS with error commands ?

Goswin von Brederlow goswin-v-b at web.de
Wed Jul 9 10:43:12 CEST 2014


On Fri, Jul 04, 2014 at 07:11:52PM +0200, Diego Duclos wrote:
> Actually, after some more consideration. As CurveZMQ runs over TCP, which
> can already be trivially DoS'd using a FIN packet, I don't think adding
> authentication will add much value to the protocol.
> 
> 
> On Fri, Jul 4, 2014 at 4:34 PM, Goswin von Brederlow <goswin-v-b at web.de>
> wrote:
> 
> > On Thu, Jul 03, 2014 at 09:24:59PM +0200, Pieter Hintjens wrote:
> > > I guess the error command could be encrypted with the server long term
> > > private key, yes.
> > >
> > > On Thu, Jul 3, 2014 at 8:15 PM, Diego Duclos
> > > <diego.duclos at palmstonegames.com> wrote:
> > > > I've been reading up the Curve spec with more detail, and the way the
> > error
> > > > packet currently works caught me by surprise. Couldn't a crafted TCP
> > packet
> > > > with an error command be sent to a client ? Tricking it into thinking
> > the
> > > > server has denied it's credentials when it has done no such thing ?
> > > > This allows someone with the ability to listen in but not block
> > packets to
> > > > do denial of service, which wouldn't be the case if the error packet
> > was
> > > > authenticated & encrypted.
> >
> > What if the error was that the servers public key didn't fit?
> >
> > MfG
> >         Goswin

Not the same I think.

If you send a FIN to the tcp connection then zmq will reconnect. So
you can disrupt zmq somewhat but it will recover.

If you send an error to the CURVE authentication then zmq will not
retry. A single well timed attack disables the connection completly.
As for the well timed you probably would need to use a FIN or
something to disrupt an existing connection and then catch the
reconnection to DOS it.

MfG
	Goswin



More information about the zeromq-dev mailing list