[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Jan 2014 16:52:18 +0000
From: "Daniel P. Berrange" <berrange@...hat.com>
To: Eric Blake <eblake@...hat.com>
Cc: cve-assign@...re.org, pmatouse@...hat.com, oss-security@...ts.openwall.com,
libvirt-security@...hat.com
Subject: Re: [Libvirt-Security] CVE Request -- libvirt: denial of service
with keepalive
On Tue, Jan 14, 2014 at 09:33:24AM -0700, Eric Blake wrote:
>
>
> On 01/14/2014 09:25 AM, cve-assign@...re.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 :|
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
