[OTR-dev] /me bug

[Ian Goldberg]

On Tue, Sep 10, 2013 at 10:25:54PM +0200, Thijs Alkemade wrote:
> 
> On 10 sep. 2013, at 20:02, Jurre van Bergen <drwhax at 2600nl.net> wrote:
> 
> > 
> > Signed PGP part
> > On 09/10/2013 07:46 PM, Jacob Appelbaum wrote:
> > > Heya,
> > >
> > > There exists an information leak in Pidgin/Pidgin-OTR where Pidgin
> > > doesn't allow Pidgin-OTR to encrypt a specific message before it is sent
> > > to the network. Specifically on IRC networks, users who emote through
> > > the use of a message such as `/me thinks this is a bug` - will leak the
> > > full text of their /me command.
> > >
> > > This is annoying and it would be nice if Pidgin didn't treat /me
> > > messages in this way. It appears that around the same time as learning
> > > about this bug, I found a bug report with a fix for Pidgin itself.
> > >
> > > If there are any Pidgin/Pidgin-OTR users on this list who also use IRC
> > > with Pidgin, it would be great to see if the following patch fixes the
> > > behavior of /me on irc:
> > >
> > >   https://developer.pidgin.im/ticket/15750
> > >
> > > This could also be fixed inside of Pidgin-otr - though I think the right
> > > place is inside of Pidgin itself. It would be useful if IRC using
> > > Pidgin-OTR developers could test the patch attached to ticket 15750 on
> > > the Pidgin bug tracker.
> > >
> > > Useful questions to answer:
> > >
> > > Does it solve the /me info leak for you? Does it cause any adverse
> > > issues? Does it make sense to put this into Pidgin-OTR?
> > >
> > > All the best,
> > > Jake
> > >
> > 
> > I tested this patch a few weeks ago and it doesn't fix the current issue
> > in IRC while being in an OTR conversation.
> > 
> > Jurre
> 
> Hello,
> 
> I'm the author of that patch. One thing to note about it is that it doesn't
> fix the decryption: If you send "/me nods." from Pidgin to Pidgin, the
> receiver will see it as "\001ACTION nods.\001" (or whatever weird characters
> GTK uses to render \001).
> 
> The possible solutions for that would be:
> 
> - Pidgin-OTR passes a decrypted message to back irc_parse_ctcp() to be handled
> like normal CTCPs. That would be a bit of a hack, as I don't think Pidgin-OTR
> currently needs to differentiate between different protocols like that and
> this would create a hard dependency between Pidgin-OTR and the IRC prpl.
> 
> - Pidgin-OTR replaces all occurances of "\001ACTION foo.\001" with "/me foo."
> when decrypting. This is not a pretty solution either, but at least it would
> not create a dependency of Pidgin-OTR on the IRC prpl.
> 
> - Pidgin-OTR uses different libpurple signals. For example by hooking "irc-
> receiving-text" and "irc-sending-text" it would be possible to encrypt every
> CTCP (including ACTION) and decrypt them while maintaining the handling for
> them by libpurple. Downside of this is that Pidgin-OTR needs to be able to
> parse and generate IRC PRIVMSGs.
> 
> The last one would also make this patch unnecessary.
> 
> I have not been able to reproduce the problem Jurre had with my patch. Using
> Pidgin on Wheezy with my patch I've verified with Wireshark that everything
> is encrypted when sending "/me".
> 
> Regards,
> Thijs

(Warning: it's been probably more than a decade since I looked at the
irc low-level protocol.)

If the user types "/me nods", what do you *want* to get sent over the
wire?

\001ACTION ?OTR:AAMD...

(which leaks that it *was* an action, and its approximate length)

\001PRIVMSG ?OTR:AAMD...

where the plaintext starts with "/me "?


In any event, isn't it the case that the prpl-irc plugin can modify the
plaintext of the action however it likes, raise sending-im-msg, and then
massage the result however it likes?  (Some care will need to be taken
to deal with fragmentation.)

   - Ian