Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Jan 2014 09:33:24 -0700
From: Eric Blake <eblake@...hat.com>
To: cve-assign@...re.org, pmatouse@...hat.com
CC: oss-security@...ts.openwall.com, libvirt-security@...hat.com,
        jdenemar@...hat.com
Subject: Re: CVE Request -- libvirt: denial of service with keepalive



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.

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

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


Download attachment "signature.asc" of type "application/pgp-signature" (605 bytes)

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.