qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 6/6] vnc: track & limit connections


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 6/6] vnc: track & limit connections
Date: Wed, 15 Oct 2014 15:39:15 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Oct 15, 2014 at 04:19:29PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > > The logic to apply the limit to connections in "connecting" state (this
> > > is the state you are in *before* successfull authentication) is
> > > slightly different:  A new connect kicks out the oldest client which is
> > > still in "connecting" state.  This avoids a easy DoS by unauthenticated
> > > users by simply opening connections until the limit is reached.
> > 
> > I'd suggest that rather than kicking off the oldest client QEMU
> > should simply stop calling accept() when it reaches the limit
> > of active unauthenticated client connections.
> 
> Looks like I need to be a bit more verbose.  The DoS I try to prevent is
> that anybody can open $limit connections to the vnc server, let them sit
> around idle, thereby blocking further connects.

Ah, so the DoS I'm thinking of is that you can open connections
to VNC until the max file descriptor limit is exhausted and thus
break anything in QEMU that needs to open a new FD (eg migration).
The key to fixing that particular DoS is simply having a small
finite limit so we cannot exhaust file descriptors. Stopping
calling accept() works in that scenario.

> Whenever you stop calling accept or drop the new connection doesn't make
> much of a difference.
> 
> 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. This
fix would only address the scenario you describe if the good guy can
connect & complete auth before the bad guy opens more connections.
With TLS and/or SASL there's a non-negligible time window for auth
to take place.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]