Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#15277 closed enhancement (fixed)

Windows installer relies on HTTP rather than HTTPS

Reported by: ioerror Owned by: datallah
Milestone: 2.10.7 Component: winpidgin (gtk)
Version: 2.10.6 Keywords: security
Cc:

Description

Summary

Pidgin's website and installer do not use HTTPS (SSL/TLS). It is not possible to download and install pidgin without being exposed to possible harm from unsophisticated attackers.

This builds on some observations in #15276

Steps to reproduce

Download pidgin - it appears to be only available over HTTP. The installer fetches further components over HTTP, including seemingly unsigned, unchecked executable code.

Expected results

Secure installation of various pidgin components.

The installer should be available over HTTPS (SSL/TLS) at the very least. The installer should download additional components over HTTPS if required *or* it should ensure that downloaded components are verified to be consistent with the expected results. It is however extremely tricky to ensure that a download operation is safe when it happens over HTTP, even with known cryptographic hashes.

Actual results

A Man-in-the-Middle may replace the downloaded files with a backdoored copy of the gtk libraries, they may corrupt or serve malformed debug symbols among many other possible issues.

Regression

None that I am aware of at this time.

Notes

Pidgin could easily 'pin' the expected cert to be any cert that is required. The only time a "valid" (aka CA signed) certificate is required is when the user downloads the actual windows installer. Otherwise, the actual libraries, components and other files may be downloaded over a pre-authenticated certificate or a certificate that is alternatively signed by a CA only trusted by the pidgin installer.

Change History (11)

comment:1 Changed 4 years ago by ioerror

Specifically, I see two urls being fetched insecurely.

It fetches the gtk files over http from this url: http://pidgin.im/win32/download_redir.php?version=2.10.6&gtk_version=2.16.6.0&dl_pkg=gtk

It also fetches debug symbols over http from this url: http://pidgin.im/win32/download_redir.php?version=2.10.6&dl_pkg=dbgsym

comment:2 Changed 4 years ago by ioerror

This is primarily the thing that seems to be a threat for these kinds of issues: http://krebsonsecurity.com/2010/11/evilgrade-gets-an-upgrade/

comment:3 Changed 4 years ago by ioerror

I suggested to the Gnome team that they should offer the gtk libs over HTTPS: https://bugzilla.gnome.org/show_bug.cgi?id=682641

comment:4 Changed 4 years ago by bleeter

  • Type changed from defect to enhancement

comment:5 follow-up: Changed 4 years ago by datallah

The pidgin.im URLs referenced here simply redirect to the SF.net download URLs.

Instead of pinning certs (which I'm pretty sure the NSISdl infrastructure wouldn't support, and wouldn't work anyway since we're actually downloading from some SF.net mirror), I think we should make the installer validate the hash of the files it downloads against the expected value (with the expected hash value either baked into the installer, or preferably, downloaded via HTTPS).

FYI there is also an "offline" installer that includes these resources in the initial download.

comment:6 in reply to: ↑ 5 Changed 4 years ago by ioerror

Replying to datallah:

The pidgin.im URLs referenced here simply redirect to the SF.net download URLs.

Instead of pinning certs (which I'm pretty sure the NSISdl infrastructure wouldn't support, and wouldn't work anyway since we're actually downloading from some SF.net mirror), I think we should make the installer validate the hash of the files it downloads against the expected value (with the expected hash value either baked into the installer, or preferably, downloaded via HTTPS).

I think it would be easier to just use HTTPS. There are a number of attacks that are possible without it - too many to count, even if you have an expected hash.

FYI there is also an "offline" installer that includes these resources in the initial download.

Is that offline installer available over SSL?

comment:7 Changed 4 years ago by ioerror

I've written an EvilGrade? module for this issue - so it provides a backdoored GTK bundle. Ironically, just as I was testing, I noticed I couldn't use the installer to download the GTK bundle or the debugging symbols. I'm not sure why the installer behavior changed but I'll get around to figuring it out in about a week. The EvilGrade? plugin will work for all files that aren't protected by HTTPS (SSL/TLS) - so it can be used as a useful regression test when HTTPS is deployed.

comment:8 follow-up: Changed 4 years ago by Daniel Atallah <datallah@…>

(In [40eb50cbc39d]):
Add support to the win32 installer to check the sha1sum of the downloaded GTK Bundle and debug symbols. Refs #15277

  • To make this worthwhile, the download redirection URL (which also serves the sha1sums) now uses https.
  • This uses a custom NSIS plugin (distributed, along with its source in the Pidgin installer deps) to do the sha1sum calculation on the downloaded resources. The plugin is based on the win32 sha1sum implementation by Werner Koch (http://lists.gnupg.org/pipermail/gnupg-announce/2004q4/000184.html).

comment:9 in reply to: ↑ 8 ; follow-up: Changed 4 years ago by ioerror

Replying to Daniel Atallah <datallah@…>:

(In [40eb50cbc39d]):
Add support to the win32 installer to check the sha1sum of the downloaded GTK Bundle and debug symbols. Refs #15277

  • To make this worthwhile, the download redirection URL (which also serves the sha1sums) now uses https.
  • This uses a custom NSIS plugin (distributed, along with its source in the Pidgin installer deps) to do the sha1sum calculation on the downloaded resources. The plugin is based on the win32 sha1sum implementation by Werner Koch (http://lists.gnupg.org/pipermail/gnupg-announce/2004q4/000184.html).

This is a good start - thanks for making it happen Daniel.

I wonder - would it be possible to make a very small stub installer that embeds all of the sha1sum hashes into it and fetches everything as expected? If so, putting that up on a secure download page seems like an absolute win for everyone.

comment:10 in reply to: ↑ 9 Changed 4 years ago by datallah

Replying to ioerror:

I wonder - would it be possible to make a very small stub installer that embeds all of the sha1sum hashes into it and fetches everything as expected? If so, putting that up on a secure download page seems like an absolute win for everyone.

That's an interesting thought. It would take some work, but it'd be possible to do.

My priority (and all I have time for right now) is to address the outstanding issues; this may be something to think about later.

comment:11 Changed 4 years ago by Daniel Atallah <datallah@…>

  • Milestone set to 2.10.7
  • Resolution set to fixed
  • Status changed from new to closed

(In [51473787ff4f]):
Bake the sha1sums for the debug symbols and gtk runtime into the installer instead of downloading them.

  • We should know both of these values at the time we build the installer
  • This also fixes stuff so that we don't regenerate the GTK Runtime after it has been published
    • The various Pidgin versions that share a GTK+ Bundle should now use exactly the same file instead of one that contains the same contents
  • Fixes #15277
Last edited 4 years ago by datallah (previous) (diff)
Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!