From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:36171)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1XeiZy-0006h6-Eg
	for qemu-devel@nongnu.org; Thu, 16 Oct 2014 06:46:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1XeiZq-0002uY-0H
	for qemu-devel@nongnu.org; Thu, 16 Oct 2014 06:46:46 -0400
Received: from mx1.redhat.com ([209.132.183.28]:7559)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1XeiZp-0002uL-PR
	for qemu-devel@nongnu.org; Thu, 16 Oct 2014 06:46:37 -0400
Message-ID: <1413456389.18160.1.camel@nilsson.home.kraxel.org>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Thu, 16 Oct 2014 12:46:29 +0200
In-Reply-To: <20141015143915.GE3741@redhat.com>
References: <1413375585-20301-1-git-send-email-kraxel@redhat.com>
	<1413375585-20301-7-git-send-email-kraxel@redhat.com>
	<20141015123110.GA3741@redhat.com>
	<1413382769.4213.5.camel@nilsson.home.kraxel.org>
	<20141015143915.GE3741@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 6/6] vnc: track & limit connections
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>, "Dr. David
	Alan Gilbert" <dgilbert@redhat.com>

  Hi,

> > I try to prevent that by dropping the *oldest* connection, so you have a
> > chance to connect even if a unprivileged attacker tries to use up all
> > connection slots.
> 
> Lets say the limit is 5. The bad guy has 5 open idle connections.
> The good guy opens a new one and pushes off one of the bad guy's
> connections. Fine so far. The bad guy though can simply open 5 more
> connections and he'll push the good guy's connection off again.

Correct.  It can't fully prevent the attack, but makes it harder to pull
off.  Just having $limit idle connects isn't enough any more, the bad
guy has to constantly bomb qemu with vnc connect requests, hoping this
kicks out the good guy before it managed to authenticate.  The chances
for the good guy are a bit better and it is also more likely that the
attack sets off alarms in network monitoring.

cheers,
  Gerd