Bug 817692 (CVE-2012-2132)
Summary: | CVE-2012-2132 libsoup: does not indicate whether or not an SSL certificate is valid | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> | ||||||
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||
Severity: | low | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | unspecified | CC: | danw, erik-fedora, mbarnes, rjones | ||||||
Target Milestone: | --- | Keywords: | Security | ||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2012-06-14 06:17:54 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | 818231, 818232 | ||||||||
Bug Blocks: | 817693 | ||||||||
Attachments: |
|
Description
Vincent Danen
2012-04-30 22:40:52 UTC
The CVE is wrong. The bug is in Midori. It is telling libsoup to trust all SSL certificates, and so then libsoup reports that all SSL certificates are trusted, just like Midori asked. To the extent that this is libsoup's fault, it's because it supports the feature Midori is trying to implement here, but doesn't document how to do it correctly. But it is *possible* to do it correctly, as seen in epiphany. The SUSE patch is just wrong, as I'm sure they will notice shortly... (eg, it will completely break https in evolution). (In reply to comment #1) > To the extent that this is libsoup's fault, it's because it supports the > feature Midori is trying to implement here, but doesn't document how to do it > correctly (and the API in question wasn't sufficiently-thought-out in advance and ended up being easy to use incorrectly...) Created attachment 581443 [details]
patch against libsoup 2.32
Created attachment 581614 [details]
patch against libsoup 2.34 (F15)
ok, apparently 2.34 had an intermediate version between the old old code in F14 and the new-and-improved code in F16.
Created libsoup tracking bugs for this issue Affects: fedora-15 [bug 818231] Created mingw32-libsoup tracking bugs for this issue Affects: fedora-15 [bug 818232] Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=666280 That's actually a different bug, though it's another aspect of the same confusing API. This bug is "if ssl-strict is FALSE and ssl-ca-file is NULL, then [something confusing]", and we can fix it. That bug is "if ssl-strict is *TRUE* and ssl-ca-file is NULL, then [something else confusing]", and we can't fix it (other than by documenting it better), because changing the behavior would break existing apps. Hm... I was doing the "fedpkg update", and realized that the Midori problem can't actually happen in F15, because Midori (indirectly) depends on ca-certificates there. (midori -> webkitgtk -> libsoup -> glib-networking -> ca-certificates). So there are no actual known problems in any supported version of Fedora or RHEL caused by this bug. Statement: Not vulnerable. This issue did not affect the versions of libsoup as shipped with Red Hat Enterprise Linux 5 and 6, as they do not include support for the SOUP_MESSAGE_CERTIFICATE_TRUSTED feature. |