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: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: danw, erik-fedora, mbarnes, rjones
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
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:
Bug Depends On: 818231, 818232    
Bug Blocks: 817693    
Description Flags
patch against libsoup 2.32
patch against libsoup 2.34 (F15) none

Description Vincent Danen 2012-04-30 22:40:52 UTC
It was reported [1] that libsoup did not verify certificates if an application using it did not explicitly specify a file with trusted root certificate authorities.  Because libsoup relies on the verification failure to clear the trust flag, it would always consider SSL connections as trusted in this circumstance.

SUSE has a patch to correct this flaw in libsoup 2.32.2 in their bugzilla [2].  Looking at the patch, it would apply to earlier versions of libsoup as well.

[1] https://bugzilla.novell.com/show_bug.cgi?id=758431
[2] https://bugzillafiles.novell.org/attachment.cgi?id=487674

Comment 1 Dan Winship 2012-05-01 14:45:08 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).

Comment 2 Dan Winship 2012-05-01 14:51:13 UTC
(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...)

Comment 4 Dan Winship 2012-05-01 18:43:19 UTC
Created attachment 581443 [details]
patch against libsoup 2.32

Comment 6 Dan Winship 2012-05-02 13:19:30 UTC
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.

Comment 8 Stefan Cornelius 2012-05-02 14:13:44 UTC
Created libsoup tracking bugs for this issue

Affects: fedora-15 [bug 818231]

Comment 9 Stefan Cornelius 2012-05-02 14:13:49 UTC
Created mingw32-libsoup tracking bugs for this issue

Affects: fedora-15 [bug 818232]

Comment 10 Vincent Danen 2012-05-02 22:15:56 UTC
Upstream bug:


Comment 11 Dan Winship 2012-05-03 12:52:56 UTC
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.

Comment 12 Dan Winship 2012-05-03 15:18:08 UTC
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.

Comment 13 Stefan Cornelius 2012-05-03 16:22:44 UTC

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.