Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 17 Jan 2014 11:06:39 +1100
From: Murray McAllister <mmcallis@...hat.com>
To: oss-security@...ts.openwall.com
CC: krahmer@...e.de
Subject: Re: CVE already assigned for 1026891?

On 12/19/2013 01:11 PM, Murray McAllister wrote:
> On 12/19/2013 06:58 AM, Vincent Danen wrote:
>>
>> On Dec 18, 2013, at 12:43 PM, cve-assign@...re.org wrote:
>>
>>> Signed PGP part
>>> http://www.openwall.com/lists/oss-security/2013/12/18/3 raises the
>>> question of whether there is a CVE assignment in
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1026891 already, in order
>>> to avoid a duplicate assignment. Our guess is that security issues
>>> tracked privately by Red Hat typically do have pre-assigned CVE IDs,
>>> so MITRE will delay a CVE assignment indefinitely.
>>>
>>> Although it would be great to know what CVE ID you have assigned,
>>> replying with something like "yes, it has a CVE ID, but it's only
>>> being shared with the embargo audience" would be quite useful as well.
>>
>> There is a CVE assigned to this, but based on what Sebastian wrote, I can’t tell if it’s the same issue so I’m hesitant to say what the CVE is in case it does end up being different.
>>
>> Sebastian, can you give me access to your bug?  Or did you intend to make it public?  I’m assuming that since you are asking about a CVE here, you maybe did not mean to keep it private?  Your other message said your bug contained upstream URLs (so maybe even pasting those here would be helpful).
>>
>> Once I can look at it, I can let you know for sure whether or not it is the same issue (and should then use the same CVE).
>>
>> Thanks.
>>
>> —
>> Vincent Danen / Red Hat Security Response Team
>>
>
> Hi all,
>
> Sorry for the poor handling here on my part, the build in Fedora took me
> by surprise...There are two pywbem CVEs (assigned by Red Hat):
>
> CVE-2013-6418 is about pywbem doing an SSL connection with verification
> enabled, closing it, and doing the real data transfer over another
> connection with verification disabled.
>
> CVE-2013-6444 is about pywbem failing to verify the URI matches the
> Subject of the certificate (missing hostname check).
>
> According to
> http://sourceforge.net/mailarchive/message.php?msg_id=31757312 both of
> these CVEs are fixed by the following patch:
>
> http://sourceforge.net/mailarchive/attachment.php?list_name=pywbem-devel&message_id=52AF1EE9.8080805%40redhat.com&counter=1
>
> However, I don't think that is the final fix, and I'm in the wrong
> timezone to ask :( so I'm just going to paste the comments from a bug I
> won't be able to open:
>
> ""
> +        for path in (
> +                '/etc/pki/tls/certs',
> +                '/etc/ssl/certs',
> +                '/etc/ssl/certificates'):
> +            if os.path.exists(path):
> +                get_default_ca_certs._path = path
> +                break
>
> I'm not sure if this works because the /etc/pki/tls/certs directory does
> not contain individual PEM certificate files under special hashed file
> names, which is what SSL_CTX_load_verify_locations expects.
>
> +            ctx = SSL.Context('sslv3')
>
> The above results in an SSL 3.0 client hello:
>
>          Handshake Protocol: Client Hello
>              Handshake Type: Client Hello (1)
>              Length: 121
>              Version: SSL 3.0 (0x0300)
>              Random
>                  gmt_unix_time: Dec 17, 2013 13:37:12.000000000 CET
>                  random_bytes:
> xxx
>              Session ID Length: 0
>
> You need to use 'sslv23' to get the most recent protocol version.
> ""
>
> ""
> I've gathered some information about the paths you mentioned. I agree
> this approach is not correct. Perhaps this is better:
>
>          for path in (
>                  # newer distributions using update-ca-trust
>                  '/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt',
>                  # use these directories as a fallback
>                  '/etc/ssl/certs',
>                  '/etc/ssl/certificates'):
>              if os.path.exists(path):
>                  get_default_ca_certs._path = path
>                  break
>
> On f19+, update-ca-trust is used to regenerate ca bundles under
> /etc/pki/ca-trust/extracted directory. As you say it's wrong to use
> directory path here, since cacertdir_rehash is not used to make symlinks
> with hashes.
> On f18 and older, '/etc/ssl/certs' is used with symlinks created by
> cacertdir_rehash.
>
> If '/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt' does not
> exist, the '/etc/ssl/certs' will be used as a fallback.
> ""
>
> I will open our bugs soon
> (https://bugzilla.redhat.com/show_bug.cgi?id=1039801 and
> https://bugzilla.redhat.com/show_bug.cgi?id=1044246).
>
> Apologies again for the mess here and lack of a heads up before it went
> public.
>
> --
> Murray McAllister / Red Hat Security Response Team
>

Final fix: https://bugzilla.redhat.com/attachment.cgi?id=851357

This fixes CVE-2013-6418 
(https://bugzilla.redhat.com/show_bug.cgi?id=1039801) and CVE-2013-6444 
(https://bugzilla.redhat.com/show_bug.cgi?id=1044246).

--
Murray McAllister / Red Hat Security Response Team

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.