MEDIA // Libpurple based IMs

[Ethan Blanton]

Joseph Cox spake unto us the following wisdom:
> Hey, thanks for the information.
> 
> Sure: the main issues I've come across with libpurple, and then Pidgin
> on top of this, in my research are that:

OK.  These are unsurprising, and relatively common
misinformation/misconceptions, but like most such common errors, they
contain a grain of truth.

> - libpurple is a very large library, meaning that bugs are often
> discovered within it, particularly memory corruption bugs.

This is true, libpurple is very large.  This is always a disadvantage.
However, it does not necessarily mean that it is particularly *bad*
for its size.  While one can expect a more or less constant lower
bound on the number of bugs per line of code (Cf. Frederick Brooks and
reams of later study), thus suggesting that larger code means more
bugs, it's also that case that libpurple is effectively partitioned in
such a way that no given account touches large parts of that code; for
example, a bug in the Yahoo! protocol will not adversely affect an
XMPP account.  On the other hand, the multi-protocol nature of
libpurple means that that XMPP account probably descends through a
deeper software stack than a single-protocol client would use.

I don't think that libpurple is going to be particularly larger than
another *multiprotocol* IM library, nor contain particularly more
bugs.  Individual protocol plugins may.  In particular, some protocol
plugins have been provided to us by third parties and may even require
accounts on IM networks that we do not or cannot use (such as
corporate messenger servers).

> - Pidgin does not enable end-to-end encrypted messages by default, but
> these are handled by the OTR plugin, which is not baked into the design.

This is true, but it is true of all OTR clients, to my knowledge. Some
ship the OTR plugin with the client itself, but OTR does not provide a
client.  Note that our intention is to ship the OTR plugin with Pidgin
3 when it is released.  Note also that this will not make it "baked
in", it will simply be a first-party-supported plugin.  Some libpurple
clients (such as Adium for OS X) already provide first-party support
for OTR.

There is a real lack in the market of an end-to-end secure instant
messaging protocol with widespread adoption and sound security
practices.  There are some relatively recent entries (such as Whisper
Systems' TextSecure, which unfortunately relies on their commercial
servers unlike, say, XMPP; Tox; etc.), but they generally either have
significant flaws or are not yet well-adopted.  (In some cases a
protocol plugin could be provided for libpurple, and in some cases
there are already third-party protocol plugins.)

Thus OTR.  OTR runs on top of existing, established IM networks and
provides a fair measure of end-to-end security.

> - and that some members of the infosec community seem to think that
> Pidgin developers take a lot of time to patch vulnerabilities (see this
> tweet from Appelbaum: https://twitter.com/ioerror/status/525622470666358784)

That tweet is subtle and may not mean what you think it means.  The
bug in question was actually simply an instance of a general error
first published by Moxie Marlinspike two years before the reporting
and correction of the related bug in Pidgin.  Jacob's point was more
despair that Moxie's bug was still relevant, I think.  In any case,
the underlying problem was a lack of functionality in the open source
SSL/TLS libraries NSS and GnuTLS (certificate basic constraints
validation), for which we had a workaround.  Certainly it would have
been good for us to have fixed the bug earlier, but it's not like we
had a specific security-related bug report that we sat on for years.

> Various people from the same infosec community have been switching to
> Adam Langley's command line xmpp-client, and some have been using CoyIM,
> based on top of this, both written in Go. Any thoughts you might have on
> those clients would be appreciated too.

I have used neither project, and cannot comment.  Other Pidgin
developers may have some comment.

We have a lot of thoughts about security within the libpurple team,
and we have differing positions on the various reoccurring accusations
that libpurple is insecure.  Broadly speaking, I think we feel that
most such accusations are either a) in denial of the state of security
of Internet-connected software in general and of our application of
rasonable practices to the problem, b) tied to specific errors that
the accuser sees as more important than we believe the merits of
libpurple are in a larger context, or c) general concerns that large
software has lots of bugs (hello, web browsers!).  Certainly we have
had bugs, and bad bugs, in the past, and certainly there are design
decisions in libpurple that would be best reconsidered if we were
starting a library today but were either necessary or even best
practice in the 90s (such as implementing network protocols in C).

Note that we maintain a list of known security flaws in released
versions of libpurple, that we issue CVEs proactively for flaws we
find ourselves, and that we coordinate flaws (discovered in-house or
reported by external developers) with packagers and distributions to
make timely disclosures with available fixes for remotely-triggerable
flaws.  (See https://pidgin.im/security/ and
https://pidgin.im/news/security/ .) Note also that the last major
reported flaws were in late 2014, meaning libpurple went through all
of 2015 without any first- or third-party reported flaws requiring
disclosure.  That does NOT mean that there will not be remote exploit
flaws reported tomorrow, or that there aren't lurking bugs with severe
consequences (Cf. OpenSSL!), but I think it does indicate that we take
security seriously and have a mature code base.

Of course, if any given user finds that another client better responds
to their threat analysis or has a better, more secure implementation,
then we absolutely encourage that user to adopt the software that they
trust best.  We would also love to know why that decision was made and
how we might improve libpurple to meet their threat model head-on, but
such things still take time and may not be possible at all.  (E.g., we
are unlikely to make libpurple a uniprotocol library simply to reduce
the attack surface!)

Hopefully there's something helpful to you there.  Good luck with your
article.  Other developers may chime in later.

Ethan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <https://pidgin.im/cgi-bin/mailman/private/security/attachments/20160204/a542ae7d/attachment.sig>