Re: Re: cve request: docker swarmkit Dos occurs by repeatly joining and quitting swam cluster as a node

[Kurt Seifried <kseifried () redhat com>]

On Thu, Sep 1, 2016 at 9:30 PM, Diogo Mónica <diogo.monica () docker com>
wrote:

> If you read the report, you'll see that no claims are made about shutting
> down the swarm. The reporter simply claims that no new nodes can join the
> swarm:
>
> "it results in a machine could not join the swarm cluster after another
> node’s repeatedly joining and quitting the swarm"


> As we describe in our documentation, possession of the token gives the
> permission to join new workers. Joining new workers effectively means
> reserving some resources for your worker. If the system runs out of
> resources, I believe it is expected that no new workers should be able to
> join.

DoS is often a gray area. Obviously if I send 10 gigabits of request
traffic and swarm gets slow/non responsive the CVE response would be "Well
yeah... that's probably what happens if you saturate the network with
requests. No CVE for you" but if a single node behaves in an odd way and
prevents the whole system from working in an expected manner, that may be a
problem that is worth a CVE, especially if it can be triggered by an
attacker/less trusted user (classic trust boundary violation to quote
@sushidude).


> Again, this is simply not a vulnerability of either Docker swarm or Docker
> swarmkit, and I kindly request that this CVE is rescinded.

Regardless of whether this is CVE worthy is there any plan to add rate
limiting or other protective measures to prevent a single badly
behaved/malicious node from making the swarm unable to operate normally? I
don't see any issues in https://github.com/docker/swarm/issues for this.
Thanks!


> On Thu, Sep 1, 2016 at 7:53 PM, Kurt Seifried <kseifried () redhat com>
> wrote:
>
> > On Thu, Sep 1, 2016 at 8:48 PM, Diogo Monica <diogo.monica () docker com>
> > wrote:
> >
> > > Can you please describe how this vulnerability makes a worker node be
> > able
> > > to administer the swarm?
> >
> > It allows a worker node to disable and effectively shut down the swarm, I
> > assume shutting down the swan is an administrative function, if not
> please
> > let me know where the documentation for workers covers this (allowing a
> > worker to shutdown the swarm). Thanks!
> >
> >
> > > On Thu, Sep 1, 2016 at 7:12 PM -0700, "Kurt Seifried" <
> > > kseifried () redhat com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Sep 1, 2016 at 5:17 PM, Diogo Mónica
> > > wrote:
> > >
> > > > A few weeks ago (Aug 4, 2016), a CVE (CVE-2016-6595) describing a DoS
> > on
> > > > docker swarm got issued. We believe this not a real issue, and would
> > like
> > > > to have the CVE rescinded.
> > > >
> > > > The person reporting this "vulnerability" is exhausting the resources
> > of
> > > a
> > > > remote manager by doing hundreds of join/leave operations without
> > > removing
> > > > the state that is left by old nodes. At some point the manager
> > obviously
> > > > stops being able to accept new nodes, since it runs out of memory.
> > > >
> > > > Given that both for Docker swarm and for Docker Swarmkit nodes are
> > > > *required* to provide a secret token (it's actually the only mode of
> > > > operation), this means that no adversary can simply join nodes and
> > > exhaust
> > > > manager resources.
> > > >
> > > > We can't do anything about a manager running out of memory and not
> > being
> > > > able to add new legitimate nodes to the system. This is merely a
> > resource
> > > > provisioning issue, and definitely not a CVE worthy vulnerability.
> > >
> > > I checked the documentation and it looks like a worker node is only
> > > supposed to work and is not supposed to be able to administer the
> swarm.
> > As
> > > such this is a trust boundary violation, and needs a CVE.
> > >
> > >
> > >
> > > > Thank you,
> > > > --
> > > > Diogo Mónica
> > >
> > >
> > >
> > > --
> > >
> > > --
> > > Kurt Seifried -- Red Hat -- Product Security -- Cloud
> > > PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> > > Red Hat Product Security contact: secalert () redhat com
> >
> >
> > --
> >
> > --
> > Kurt Seifried -- Red Hat -- Product Security -- Cloud
> > PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> > Red Hat Product Security contact: secalert () redhat com
>
>
>
> --
> Diogo Mónica



-- 

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert () redhat com