Disabling SSLv3 for 2.10.10?

[Thijs Alkemade]

On 16 okt. 2014, at 20:26, Mark Doliner <mark at kingant.net> wrote:

> Is POODLE a problem for us? I got the impression that it's not. It
> seems like it's an information leak that is only possible if the
> attacker can cause Pidgin to send many slightly different SSL/TLS
> requests. For browsers this happens if an active MITM injects
> javascript into an http response and the malicious javascript makes
> many custom https requests. I can't think of a scenario for how that
> might happen within Pidgin.
> 
> I agree that it would be nice to disable SSLv3 (or give people the
> ability to do it via a hidden pref)(FYI I disabled it for GnuTLS in
> default), but I'm worried about making this change immediately before
> releasing.

This is a very far-fetched scenario (especially because the amount of
information gained is small and the amount of capabilities the attacker needs
is large), but it is an example of how POODLE can affect Pidgin:

Suppose you're in a anonymous MUC (meaning only moderators can discover the
real JID of participants) and the attacker is in the same MUC (but not a
moderator) and wants to obtain your real JID. Being in the same MUC means the
attacker can send pings to you which get relayed by the MUC to your real JID.
These pings will contain your JID, and by adding extra attributes on the ping
the attacker is capable of changing the position of that data in the SSL
record. The attacker is also needs to have network access allowing them to
rearrange the blocks of this packet. By using the same vulnerability as
POODLE, the attacker can obtain characters of your real JID one by one by
replacing the padding with the message that contains a byte of your real JID.

Downside is that any incorrect guess will cause the connection to close, and
the attacker will likely make a lot of wrong guesses. On HTTPS the user will
be unlikely to notice, but millions of disconnects of Pidgin are hard to
ignore.

This is basically the only scenario on XMPP I can think of where an attacker
can:

- Cause something secret to be retransmitted.
- Influence the position of that secret in the SSL record.

Regards,
Thijs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://pidgin.im/cgi-bin/mailman/private/security/attachments/20141016/d1d8eafd/attachment-0001.sig>