From chris.tuchs at hushmail.com Mon Dec 14 18:27:55 2009 From: chris.tuchs at hushmail.com (chris.tuchs at hushmail.com) Date: Mon, 14 Dec 2009 15:27:55 -0800 Subject: [OTR-dev] Freeze, .NET, RPC, and other weirdness Message-ID: <20091214232755.EA1CC28040@smtp.hushmail.com> Users of OTR in Emerald recently started complaining about a freeze when they get the first OTR message. I did a little investigating and found that a bunch of strange DLL's get loaded and RPC calls get made. Are you aware of any reason that calling otrl_message_receiving() would cause any of the following to be loaded, or RPC calls made (and failed)? I include the first half of the log, I didn't bother to include the unloading of all those DLL's or 3 separate threads that stop running. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\netfxperf.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\mscoree.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\PerfCounter.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\pdh.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\odbc32.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\odbcbcp.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\odbcint.dll', Binary was not built with debug information. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CORPerfMonExt.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Aspnet_perf.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\query.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\msdtcuiu.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\atl.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\mfc42u.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\mpr.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\msdtcprx.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\mtxclu.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\clusapi.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\resutils.dll', No symbols loaded. First-chance exception at 0x7c812afb in secondlife-bin.exe: 0x000006D9: There are no more endpoints available from the endpoint mapper. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\perfdisk.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\perfnet.dll', No symbols loaded. First-chance exception at 0x7c812afb in secondlife-bin.exe: 0x000006BA: The RPC server is unavailable. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\perfos.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\perfproc.dll', No symbols loaded. First-chance exception at 0x7c812afb in secondlife-bin.exe: 0x000006BA: The RPC server is unavailable. First-chance exception at 0x7c812afb in secondlife-bin.exe: 0x000006BA: The RPC server is unavailable. First-chance exception at 0x7c812afb in secondlife-bin.exe: 0x000006BA: The RPC server is unavailable. First-chance exception at 0x7c812afb in secondlife-bin.exe: 0x000006BA: The RPC server is unavailable. First-chance exception at 0x7c812afb in secondlife-bin.exe: 0x000006BA: The RPC server is unavailable. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\pschdprf.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\traffic.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\wmi.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\rasctrs.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\rasman.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\msapsspc.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\msvcrt40.dll', No symbols loaded. 'secondlife-bin.exe': Unloaded 'C:\WINDOWS\system32\msapsspc.dll' 'secondlife-bin.exe': Unloaded 'C:\WINDOWS\system32\msvcrt40.dll' 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\schannel.dll', No symbols loaded. 'secondlife-bin.exe': Unloaded 'C:\WINDOWS\system32\schannel.dll' 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\digest.dll', No symbols loaded. 'secondlife-bin.exe': Unloaded 'C:\WINDOWS\system32\digest.dll' 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\msnsspc.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\msvcrt40.dll', No symbols loaded. 'secondlife-bin.exe': Unloaded 'C:\WINDOWS\system32\msnsspc.dll' 'secondlife-bin.exe': Unloaded 'C:\WINDOWS\system32\msvcrt40.dll' 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\msv1_0.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\cryptdll.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\rsvpperf.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\tapiperf.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\tapi32.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\rtutils.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\perfctrs.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\mprapi.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\activeds.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\adsldpc.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\perfts.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\winsta.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\utildll.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\wbem\wmiaprpl.dll', No symbols loaded. 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\loadperf.dll', No symbols loaded. If that log looks kosher, is there a way for me to make it happen during start-up of our application? A predictable pause during start up is preferable to one that can strike at any random moment when someone sends you your first OTR IM of the day. Thanks! Chris p.s. I recently had to change my email address from chris- tuchs at hushmail.com to chris.tuchs at hushmail.com This is the new correct address. From ian at cypherpunks.ca Mon Dec 14 19:53:56 2009 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 14 Dec 2009 19:53:56 -0500 Subject: [OTR-dev] Freeze, .NET, RPC, and other weirdness In-Reply-To: <20091214232755.EA1CC28040@smtp.hushmail.com> References: <20091214232755.EA1CC28040@smtp.hushmail.com> Message-ID: <20091215005356.GA20373@yoink.cs.uwaterloo.ca> On Mon, Dec 14, 2009 at 03:27:55PM -0800, chris.tuchs at hushmail.com wrote: > Users of OTR in Emerald recently started complaining about a freeze > when they get the first OTR message. I did a little investigating > and found that a bunch of strange DLL's get loaded and RPC calls > get made. Are you aware of any reason that calling > otrl_message_receiving() would cause any of the following to be > loaded, or RPC calls made (and failed)? I include the first half > of the log, I didn't bother to include the unloading of all those > DLL's or 3 separate threads that stop running. > > 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\netfxperf.dll', > No symbols loaded. > 'secondlife-bin.exe': Loaded 'C:\WINDOWS\system32\mscoree.dll', No > symbols loaded. > 'secondlife-bin.exe': Loaded > 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\PerfCounter.dll', No > symbols loaded. I bet this happens when OTR needs to generate random numbers. The first time libgcrypt needs random numbers, it does a bunch of system-level stuff to try to gather as much unpredictable state as it can. If you want to do it at startup, you should be able to just call libgcrypt's random number generator, I think. - Ian From chris.tuchs at hushmail.com Fri Dec 18 13:21:20 2009 From: chris.tuchs at hushmail.com (chris.tuchs at hushmail.com) Date: Fri, 18 Dec 2009 10:21:20 -0800 Subject: [OTR-dev] Freeze, .NET, RPC, and other weirdness Message-ID: <20091218182120.EC2282803F@smtp.hushmail.com> That does seem to be the cause and the appropriate workaround. I call libgcrypt to get a 32 bits of random data at start up of the application. Now all the strange .dll action happens, along with a freeze I assume, during start up. I no longer get the freeze during the normal operation of the application. Two "oh-yeah"s. 1: Please change the name on the software page to be just "Emerald Viewer - a Second Life Client" The PR folks decided a shorter name was better. 2: I still have sitting around as a patch the minor change I made to the fragmentation code to support Second Life's surprising out of order delivery of IM. The format, syntax and semantics of the fragments remain the same, I just changed the logic in the fragment reassembly to better handle out of order delivery. I would be happy to submit the patch, let me know. For a short while it looked like Linden Lab was going to try to ban the use of OTR. In the end they decided that there are valid use cases for private messages, that they will look at doing something similar. So my battle for privacy in Second Life has moved on to another area of their system. Thanks for the quick response! Chris On Mon, 14 Dec 2009 16:53:56 -0800 Ian Goldberg wrote: >If you want to do it at startup, you should be able to just call >libgcrypt's random number generator, I think. > > - Ian From ian at cypherpunks.ca Sun Dec 20 09:55:22 2009 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 20 Dec 2009 09:55:22 -0500 Subject: [OTR-dev] Freeze, .NET, RPC, and other weirdness In-Reply-To: <20091218182120.EC2282803F@smtp.hushmail.com> References: <20091218182120.EC2282803F@smtp.hushmail.com> Message-ID: <20091220145522.GF20373@yoink.cs.uwaterloo.ca> On Fri, Dec 18, 2009 at 10:21:20AM -0800, chris.tuchs at hushmail.com wrote: > That does seem to be the cause and the appropriate workaround. I > call libgcrypt to get a 32 bits of random data at start up of the > application. Now all the strange .dll action happens, along with a > freeze I assume, during start up. I no longer get the freeze > during the normal operation of the application. Excellent. > Two "oh-yeah"s. 1: Please change the name on the software page to > be just "Emerald Viewer - a Second Life Client" The PR folks > decided a shorter name was better. Done. > 2: I still have sitting around > as a patch the minor change I made to the fragmentation code to > support Second Life's surprising out of order delivery of IM. The > format, syntax and semantics of the fragments remain the same, I > just changed the logic in the fragment reassembly to better handle > out of order delivery. I would be happy to submit the patch, let > me know. The semantics can't be *quite* the same, right? Since there's no ID number in the fragments (unnecessary if the packets are delivered in order, possibly with drops), how do you know if: 1/2 1/2 2/2 2/2 is A B A B or A B B A? Current OTR would treat it as: A B(dropping the partial A) B ignore I guess "message ids in fragments" should be in the next version of the wire protocol. But that opens up a potential DoS attack where you send packets with holes in them, forcing the other side to keep state around (forever?). When does your patch decide that it's time to expire old partially completed messages? > For a short while it looked like Linden Lab was going to try to ban > the use of OTR. In the end they decided that there are valid use > cases for private messages, that they will look at doing something > similar. So my battle for privacy in Second Life has moved on to > another area of their system. Very cool, thanks! - Ian From chris.tuchs at hushmail.com Mon Dec 21 12:53:55 2009 From: chris.tuchs at hushmail.com (chris.tuchs at hushmail.com) Date: Mon, 21 Dec 2009 09:53:55 -0800 Subject: [OTR-dev] Freeze, .NET, RPC, and other weirdness Message-ID: <20091221175355.E8A702803F@smtp.hushmail.com> On Sun, 20 Dec 2009 06:55:22 -0800 Ian Goldberg wrote: >On Fri, Dec 18, 2009 at 10:21:20AM -0800, chris.tuchs at hushmail.com >wrote: >> [...] just "Emerald Viewer - a Second Life Client" [...] >Done. Thanks! >> 2: I still have sitting around as a patch the minor change I >> made to the fragmentation code to support Second Life's >> surprising out of order delivery of IM. The format, syntax and >> semantics of the fragments remain the same, I just changed the >> logic in the fragment reassembly to better handle out of order >> delivery. I would be happy to submit the patch, let me know. >The semantics can't be *quite* the same, right? Since there's no >ID number in the fragments (unnecessary if the packets are >delivered in order, possibly with drops), how do you know if: > >1/2 1/2 2/2 2/2 > >is A B A B or A B B A? Current OTR would treat it as: > >A B(dropping the partial A) B ignore My patch would interpret this as 1/2A (missing 2/2A) 1/2B 2/2B (missing 1/2C) 2/2C. There is of course no way to know without adding something like message ID's. In this example my code ends up assembling the same fragments that the existing OTR does, and holding onto the final fragment unlike the existing OTR. The place where mine "does better" is 2/2A 1/2A where it correctly assembles A, and the existing OTR code throws away the second half of A, keeps the first half of A, and waits until another message arrives. >I guess "message ids in fragments" should be in the next version >of the wire protocol. But that opens up a potential DoS attack >where you send packets with holes in them, forcing the other side >to keep state around (forever?). When does your patch decide >that it's time to expire old partially completed messages? My code has an additional vulnerability not in the existing OTR. If my code sees 1/99999, 1/99999, 1/99999 it will free, malloc, initialize, free, malloc, initialize ... the same approximately half meg of memory. When it sees x/Y it allocates a array of Y char*'s, sets all to null, then set's [x] to point at the message fragment just received. There are no timers, and my code make decisions when it sees fragments. As soon as it sees x/Y it decides: if Y is the same, and x is a duplicate; or if Y is different from last time, throw away the old message, and start assembling a new one. After adding [x], check the count of received fragments, if it is Y we just got the last fragment, whatever number x happens to be. Something like message ID's is probably a good idea, though I would do something more like TCP. Message ID's would force use to deal with 1/99999id1, 1/99999id2, 1/99999id3... as a DOS type attack. I think looking at TCP's sliding window and not using message ID's but rather byte numbers would be the way to go. Each fragment would ACK the last byte correctly received from the other end, and indicate the offset of the first byte of this message. We could define a well known buffer size all OTR's implement, something reasonable like 32K maybe, and solve both my new vulnerability, and the existing vulnerability of having to assemble huge but undecipherable messages. But it really bugs me to be adding (parts of) TCP in the guts of a cryptographic protocol of an IM client. What is the least we can get away with? Lost messages and out of order messages are not uncommon in Second Life. I may have seen duplicate messages, it's hard to tell, but mangled messages I have never seen. I don't know the character of the many other protocols OTR has to live with, though I will probably look at IRC soon. This is a slightly edited excerpt from the diff I have laying around. This is just the code that decides what to do with a fragment k/n. if (k > 0 && n > 0 && k <= n && start > 0 && end > 0 && start < end) { k--; if (!context->fragments) { /* starting a new fragmented message */ err = otrl_malloc_fragments(context, n); if (err) return OTRL_FRAGMENT_INCOMPLETE; /* $TODO$ */ } else if (n != context->fragment_n) { /* must be starting a new message, but we didn't get * all of the old one $TODO$ send a NAK */ otrl_free_fragments(context); err = otrl_malloc_fragments(context, n); if (err) return OTRL_FRAGMENT_INCOMPLETE; /* $TODO$ */ } else if (context->fragments[k]) { /* We already got fragment K. Not likely to be a * duplicate, so this must be for a new message. But * we didn't get all of the old one $TODO$ send a * NAK */ otrl_free_fragments(context); err = otrl_malloc_fragments(context, n); if (err) return OTRL_FRAGMENT_INCOMPLETE; /* $TODO$ */ } err = otrl_add_fragment(context, k, end - start - 1, tag + start); if (err) return OTRL_FRAGMENT_INCOMPLETE; /* $TODO$ */ if (context->fragment_k == context->fragment_n) { err = otrl_assemble_fragments(unfragmessagep, context); if (err) return OTRL_FRAGMENT_INCOMPLETE; /* $TODO$ */ else return OTRL_FRAGMENT_COMPLETE; } else { res = OTRL_FRAGMENT_INCOMPLETE; } } Chris From paul at darkrain42.org Thu Dec 31 02:26:03 2009 From: paul at darkrain42.org (Paul Aurich) Date: Wed, 30 Dec 2009 23:26:03 -0800 Subject: [OTR-dev] [PATCH] Assertion failures in Pidgin-otr Message-ID: <4B3C520B.9030509@darkrain42.org> The attached patches fixes some assertion failure when initially loading the Pidgin OTR plugin as well as when opening the preference pane. Both of these are on top of v3.2.0, but should apply to CVS head. Cheers, ~Pau -------------- next part -------------- A non-text attachment was scrubbed... Name: otr-assertions.patch Type: text/x-diff Size: 990 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: otr-config-assertions.patch Type: text/x-diff Size: 1087 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: