Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ