Re: [Libvirt-Security] CVE Request -- libvirt: denial of service with keepalive

["Daniel P. Berrange" <berrange () redhat com>]

On Tue, Jan 14, 2014 at 09:33:24AM -0700, Eric Blake wrote:
> On 01/14/2014 09:25 AM, cve-assign () mitre org wrote:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1047577
> >
> > > This is now fixed upstream by v1.2.1-rc1-33-g173c291:
> >
> > > To avoid the crash, virNetServerClientStartKeepAlive needs to check if
> > > the connection is still open before starting keep-alive protocol.
> >
> > Use CVE-2014-1447 for this issue in which the product does not check
> > whether the connection is still open. This corresponds to
> > 173c2914734eb5c32df6d35a82bf503e12261bcf, which apparently would be of
> > some value in some attack scenarios.
> >
> >
> > > And really fixed by v1.2.1-rc1-37-g066c8ef:
> >
> > > it is possible to hit a window when client->keepalive is NULL while
> > > client->sock is not NULL. I was thinking client->sock == NULL was a
> > > better check for a closed connection but apparently we have to go with
> > > client->keepalive == NULL to actually fix the crash.
> >
> > Use CVE-2014-1448 for this issue in which the product does not
> > properly check whether the connection is still open. This corresponds
> > to 066c8ef6c18bc1faf8b3e10787b39796a7a06cc0, which apparently is of
> > value in additional attack scenarios.
> >
> > In deciding to SPLIT, all of these factors were considered but we
> > don't want to try to precisely specify whether any one factor would be
> > sufficient on its own:
>
> The libvirt team thinks the decision to SPLIT was overkill, and that a
> single CVE would have been sufficient.
>
> > 1. There seem to be two distinct version-like identifiers,
> > v1.2.1-rc1-33-g173c291 and v1.2.1-rc1-37-g066c8ef, which can be
> > interpreted as different affected versions.
>
> Neither of those versions is released.  The only released version is 1.2.1.
>
> > 2. The first patch alone was accepted in the
> > https://www.redhat.com/archives/libvir-list/2014-January/msg00532.html
> > and
> > https://www.redhat.com/archives/libvir-list/2014-January/msg00554.html
> > messages.
>
> Yes, it took two patches to fully fix the issue.  But the symptoms of
> the issue are identical (you either have the connection issue, or you
> don't, and it wasn't until the second patch that you get rid of the
> connection issue).  But this is no different to other cases of fixing
> bugs in unreleased code.
>
> > 3. http://libvirt.org/downloads.html says "Once an hour, an automated
> > snapshot is made from the git server source tree. These snapshots
> > should be usable." This suggests that a "version" with only the first
> > patch was, in some realistic sense, "packaged for distribution," and
> > could conceivably be in use somewhere.
>
> No, the hourly builds are NOT supported releases; we can update the
> downloads.html page to explicitly mention that they are to be used at
> own risk.

Agreed, there is only one single issue here. GIT snapshots do not count
as end user packaged releases - if you were to take that view, then every
single git commit would have be considered a 'package' since gitweb has
a link to download a .zip of any revision. Clearly that ways lies insanity.

> However, since you have already assigned both numbers, we can go ahead
> and use them :(

It makes no sense for us to use 2 distinct CVEs for this. There is only
one single issue we're going to document and manage here. Just use the
first assigned CVE-2014-1447  and discard -1448

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