Slides that were presented at SecTalks in Perth that runs through a light code review of libpurple, shows a few example findings, including CVE-2013-6485 and a few others. These bugs were fixed in Pidgin 2.10.8 on Jan 28th 2014.

1. shooting clay pidgins
a preliminary look at libpurple

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

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

4. 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
Greppable
bugs
Top-down
bugs
Where is it at?
Bottom-up
bugs

5. historical vulnerabilities
•
•
•
•
Over 50 CVE’s since Oct 2005
Mostly crashes/overflows
File* issues (arb. fr/fw)
SSL/TLS issues (MITM, etc.)

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

7. devs and components

8. devs and components

9. devs and components
Sometimes many devs touching 1 component
Sometimes only 1 touching specific plugins

10. initial code sweep
• Skim calls to purple_debug_{error|info|warn}
• Search for *alloc’s and backtrace
• Search for *printf’s and backtrace

11. a sample of findings
shooting clay pidgins

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

13. 1. process chunked data vulnerability (util.c)
G_GSIZE_MODIFIER is unsigned

14. 1. process chunked data vulnerability (util.c)
SPOT THE BUG?

15. 1. process chunked data vulnerability (util.c)
Bug #1: sz we control off the wire, int overflow here

16. 1. process chunked data vulnerability (util.c)
Bug #2 Just a debug macro and they forgot the break; so this check was pointless anyway.

17. 1. process chunked data vulnerability (util.c)
Bug #2 Just a debug macro and they forgot the break; so this check was pointless anyway.

18. 1. process chunked data vulnerability (util.c)
Overflow here and also a potential out-of-bounds read.

19. problem triaging
Found it hard to triage/trace bugs without stumbling on more things…

20. 2. sloppiness: msn_message_gen_payload
A funny example of sloppiness, probably not triggerable remotely.

21. 2. sloppiness: msn_message_gen_payload
Bug: Always increments n by 2 as g_strlcpy returns the size of the src

22. 2. sloppiness: msn_message_gen_payload
Nevermind though, we’ll just copy the message data ontop of it all anyway

23. 3. poor design: http content-length
Different protocol parsers implementing their own Content-Length parsing – many in sloppy ways

24. 3. poor design: http content-length
Different protocol parsers implementing their own Content-Length parsing – many in sloppy ways

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

26. 3. poor design: http content-length
broken way to parse content-length #1

27. 3. poor design: http content-length
broken way to parse content-length #2

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

29. 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:
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
• A slight concern about volume of fixes in each release

30. results summary
Spent no more than 1-2 days total reading through code…
Greppable
bugs
Top-down
bugs
I didn’t get past here…
Bottom-up
bugs

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

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

33. 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 

34. conclusions
+1

35. conclusions
+1

36. questions?
@volvent