Pidgin MSN memory corruption issue

[Jan Lieskovsky]

Hi Mark,

   thanks for the reproducer.

Regarding the crash mentioned in gdb.txt:

(19:43:24) msn: switchboard send msg..
(19:43:24) GLib: g_queue_is_empty: assertion `queue != NULL' failed
(19:43:24) g_log: msn_cmdproc_send_trans: assertion `cmdproc != NULL' failed

Program received signal SIGSEGV, Segmentation fault.

What was the version of Pidgin, you reproduced on?

Tried two Fedora's ones (pidgin-2.6.5-1 already with the CVE-2010-0013
patch applied) and pidgin-2.6.4-1, got two Hotmail MSN accounts:

iankko at hotmail.com/somePass, iankkotest at hotmail.com/somePass

when logged into Pidgin (started under gdb) as 'iankkotest', starting up the java
PidginExploit in the form of:

java PidginExploit iankko at hotmail.com somePass iankkotest at hotmail.com

and inviting 'iankko at hotmail.com' from 'iankkotest at hotmail.com'
(see attached further_steps.txt), the only (verbose) gdb output, I can see is
(attached result.txt) -- no crash, just some assertion message.

Could you advice, what I am doing wrong here? (Or once Pidgin was
patched for CVE-2010-0013, the crash isn't present anymore, just
some valgrind warnings?)

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

Mark Doliner wrote:
> I finally had time to look at this.  Using the proof of concept code I
> can trigger 3 errors from valgrind memcheck.  Elliott's patch
> (attached again here, for convenience) fixes the more serious two.
> The remaining problem is "Conditional jump or move depends on
> uninitialised value(s)."  I'm not sure if it's harmful, but I think it
> makes sense to fix it now.
> 
> I'm also attaching the Java proof of concept code from Fabian
> Yamaguchi because I didn't see on the packagers mailing list, and it
> seemed possible that packagers would want to try it.
> 
> Steps to use the proof of concept:
> 1. Install the java, javac and ant binaries.  This is distribution
> specific.  I believe most major distros have packagers for them (java
> and javac are often packaged together).
> 2. mkdir pidgin_CVE-2010-0277
> 3. Save the proof of concept code to this directory
> 4. svn co https://java-jml.svn.sourceforge.net/svnroot/java-jml/trunk java-jml
> 5. cd java-jml/build
> 6. ant
> 7. cd ../../
> 8. tar zxvf pidginMemoryCorruption.tar.gz
> 9. cd pidginMemoryCorruption/trigger/
> 10. javac -classpath ../../java-jml/dist/jml-1.0b5-full.jar
> PidginExploit.java Base64.java
> 11. java -classpath
> ../../java-jml/lib/httpcore.jar:../../java-j/dist/jml-1.0b5-full.jar:./
> PidginExploit meebomarkdol at hotmail.com meebouser
> mmeebotest at hotmail.com
> 
> If anyone would like me to run the proof of concept attack against one
> of their MSN accounts I can certainly do that.  Feel free to IM me at
> mark.doliner at gmail.com.
> 
> --Mark
> 
> On Mon, Jan 25, 2010 at 3:11 PM, Josh Bressers <bressers at redhat.com> wrote:
>> ----- "Paul Aurich" <paul at darkrain42.org> wrote:
>>
>>> At Warren's request (and because Josh Bressers had a question about it
>>> that I don't feel qualified to answer) here are some details on the
>>> other MSN issue discussed in Fabian Yamaguchi's talk at 26C3. Please
>>> note that the details of this vulnerability are not yet public, nor is
>>> this necessarily the final version of the patch.
>>>
>> My question was, I see that slplink allocated but not freed. I've not
>> looked at all the source though, so it's very likely freed elsewhere.
>>
>> As my java-fu is crap, I can't get the exploit to build and run
>> (if someone could build a jar of a working exploit, that would be helpful
>> for analysis and testing purposes).
>>
>> My understanding from reading the mail is that we're looking at a use after
>> free sort of flaw? If that's true, it's possibly exploitable, but will
>> likely be hard to exploit beyond a crash.
> 
> That sounds accurate to me.
> 
>> This also leads me to wonder. The default pidgin behavior is to accept
>> messages from users not on your buddy list. This is probably not ideal from
>> a security point of view. Perhaps it would make sense to either not allow
>> this by default or investigate something where before pidgin processes
>> unknown messages, it prompts the user?
> 
> Perhaps, but that's a complex change.  You often have to partially
> process a message before you know who it's from.
> 
> --Mark
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Packagers mailing list
> Packagers at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/packagers

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: result.txt
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20100210/b0702f14/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: further_steps.txt
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20100210/b0702f14/attachment-0001.txt>