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