Shooting clay pidgins

6,712 views

Published on

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.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,712
On SlideShare
0
From Embeds
0
Number of Embeds
595
Actions
Shares
0
Downloads
12
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Shooting clay pidgins

  1. 1. shooting clay pidgins a preliminary look at libpurple
  2. 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. 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. 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. 5. historical vulnerabilities • • • • Over 50 CVE’s since Oct 2005 Mostly crashes/overflows File* issues (arb. fr/fw) SSL/TLS issues (MITM, etc.)
  6. 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. 7. devs and components
  8. 8. devs and components
  9. 9. devs and components Sometimes many devs touching 1 component Sometimes only 1 touching specific plugins
  10. 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. 11. a sample of findings shooting clay pidgins
  12. 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. 13. 1. process chunked data vulnerability (util.c) G_GSIZE_MODIFIER is unsigned
  14. 14. 1. process chunked data vulnerability (util.c) SPOT THE BUG?
  15. 15. 1. process chunked data vulnerability (util.c) Bug #1: sz we control off the wire, int overflow here
  16. 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. 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. 18. 1. process chunked data vulnerability (util.c) Overflow here and also a potential out-of-bounds read.
  19. 19. problem triaging Found it hard to triage/trace bugs without stumbling on more things…
  20. 20. 2. sloppiness: msn_message_gen_payload A funny example of sloppiness, probably not triggerable remotely.
  21. 21. 2. sloppiness: msn_message_gen_payload Bug: Always increments n by 2 as g_strlcpy returns the size of the src
  22. 22. 2. sloppiness: msn_message_gen_payload Nevermind though, we’ll just copy the message data ontop of it all anyway
  23. 23. 3. poor design: http content-length Different protocol parsers implementing their own Content-Length parsing – many in sloppy ways
  24. 24. 3. poor design: http content-length Different protocol parsers implementing their own Content-Length parsing – many in sloppy ways
  25. 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. 26. 3. poor design: http content-length broken way to parse content-length #1
  27. 27. 3. poor design: http content-length broken way to parse content-length #2
  28. 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. 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. 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. 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. 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. 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. 34. conclusions +1
  35. 35. conclusions +1
  36. 36. questions? @volvent

×