Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Shooting clay pidgins

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.

  • Be the first to comment

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

    Be the first to comment

    Login to see the comments

  • MajorHayden

    Jan. 30, 2014
  • jcran

    Jan. 31, 2014

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.

Views

Total views

7,185

On Slideshare

0

From embeds

0

Number of embeds

595

Actions

Downloads

13

Shares

0

Comments

0

Likes

2

×