[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52B255CB.90907@redhat.com>
Date: Thu, 19 Dec 2013 13:11:23 +1100
From: Murray McAllister <mmcallis@...hat.com>
To: oss-security@...ts.openwall.com
CC: cve-assign@...re.org, krahmer@...e.de
Subject: Re: CVE already assigned for 1026891?
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
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.
