shooting clay pidginsa preliminary look at libpurple

introduction

• Libpurple is used by Pidgin & Adium• Pidgin was originally gaim, dating back to 1998

• People everywhere use this software

• Gets increased popularity due to OTR support

• And yet many say it’s horribly insecure? • But most don’t back it up with any evidence

process

So, in short sporadic 30~min blocks in 2013…

...when bored on planes, etc.

.. spent bits of time reading over some code…

… and then try to find time to type up bugs

the goal

• Focus on seeing code quality rather than finding exploitable bugs

• Try to suss out the general security maturity of the project

• See the developer responses/culture for security-related bugs

Greppablebugs

Top-down bugs

Bottom-up bugs

Where is it at?

historical vulnerabilities

• Over 50 CVE’s since Oct 2005

• Mostly crashes/overflows

• File* issues (arb. fr/fw)

• SSL/TLS issues (MITM, etc.)

architecture & code

• Not much documentation

• Appears to be huge attack surface

• Many protocol parsers• Dispersed dev. responsibilities

• Core code is large (logging, etc.)

• Mostly all written in C (Glib)

devs and components

devs and components

devs and components

Sometimes many devs touching 1 component

Sometimes only 1 touching specific plugins

initial code sweep

• Skim calls to purple_debug_{error|info|warn}

• Search for *alloc’s and backtrace

• Search for *printf’s and backtrace

a sample of findings

shooting clay pidgins

3 examples to show…

1. An overflow when parsing chunked HTTP responses

2. An example of just silly sloppy code

3. An example of poor/dangerous design (and sloppy code)

1. process chunked data vulnerability (util.c)

G_GSIZE_MODIFIER is unsigned

1. process chunked data vulnerability (util.c)

SPOT THE BUG?

1. process chunked data vulnerability (util.c)

Bug #1: sz we control off the wire, int overflow here

1. process chunked data vulnerability (util.c)

Bug #2 Just a debug macro and they forgot the break; so this check was pointless anyway.

1. process chunked data vulnerability (util.c)

Bug #2 Just a debug macro and they forgot the break; so this check was pointless anyway.

1. process chunked data vulnerability (util.c)

Overflow here and also a potential out-of-bounds read.

problem triaging

Found it hard to triage/trace bugs without stumbling on more things…

2. sloppiness: msn_message_gen_payload

A funny example of sloppiness, probably not triggerable remotely.

2. sloppiness: msn_message_gen_payload

Bug: Always increments n by 2 as g_strlcpy returns the size of the src

2. sloppiness: msn_message_gen_payload

Nevermind though, we’ll just copy the message data ontop of it all anyway

3. poor design: http content-length

Different protocol parsers implementing their own Content-Length parsing – many in sloppy ways

3. poor design: http content-length

Different protocol parsers implementing their own Content-Length parsing – many in sloppy ways

3. poor design: http content-length

Different protocol parsers implementing their own Content-Length parsing – many in sloppy ways

%d’s atoi(), etc. for parsing Content-Length is reminiscent of 10+ year old httpd bugs

3. poor design: http content-length

broken way to parse content-length #1

3. poor design: http content-length

broken way to parse content-length #2

general badness

• Many protocol plugins appear to implement their own parsers • HTML/XML/HTTP - e.g. Content-Length

• Signed integers for offsets/lengths/indexes is very common

• The heavy use of HTML and HTTP parsing also introduces some interesting web-related attack vectors (XSS in HTML logging, etc.)

responses

• 100% response rate, fairly understanding, quite good to deal with

• Took sometime for a patch to hit the public, e.g. CVE-2013-6485:

• A slight concern about volume of fixes in each release

8/8/2013

• Initial bug report

18/8/2013

• Follow-up email

20/8/2013

• Acknowledgement

21/8/2013

• Patch ready

28/01/2014

• Fix public

results summary

Greppablebugs

Top-down bugs

Bottom-up bugs

I didn’t get past here…

Spent no more than 1-2 days total reading through code…

latest news

• 2.10.8 was released on 28th Jan 2014 addressing 18 CVE’s• The http/chunked bug was assigned CVE-2013-6485

• A number of CVE’s in 2.10.8 (reported by Sourcefire VRT) related to Content-Length parsing, e.g: CVE-2013-6490 and CVE-2013-6487

• A lot of other patches that didn’t receive CVE’s (sloppy code)

• A lot of areas that could be looked at in more depth, e.g.• All FILE* related paths and operations (i.e. reliable/effective RCE)

• More focus on the core, such as logging, etc.

2.x versus 3.x

• So, the 2.x branch certainly has some old/sloppy code• It’s getting better each release, but there’s a lot more in there…

• The 3.x branch appears to be the more strategic solution• Cleaned up design with a tidier API (e.g. http parsing, etc.)

• A lot of dead/redundant code elimination and clean-ups

• Apparently it’s coming in the next 3-6 months

• Looks promising, but they need help to make it robust

conclusions

• Tread carefully running the 2.x version• There’s undoubtedly a lot more dangerous bugs there

• At least run on a modern platform in an isolated VM

• Alternatively take a look at Jitsi

• Keep an eye out for when the 3.x branch drops• And if you like auditing code, help out the team

conclusions

+1

conclusions

+1

questions?@volvent