[OTR-users] OTR and OpenSSL Heartbleed vulnerability?

[Ximin Luo]

On 16/04/14 21:32, Bernard Tyers - ei8fdb wrote:
> 
> On 9 Apr 2014, at 17:55, Ian Goldberg <ian at cypherpunks.ca> wrote:
> 
>> OTR is a protocol.  Different implementations of the protocol might use
>> different libraries.  But it doesn't really matter what library the OTR
>> implementation uses; if a vulnerable openssl is used in your IM client
>> *at all*, you're vulnerable.
>>
>> The standard libotr uses libgcrypt, for the record.
> 
> Hi Ian,
> 
> Can you explain when where an IM client would use openssl in terms of OTR? I think I am misunderstanding the your comment. 
> 
> I’d like to know how IM clients (if any) could be affected, in terms of OTR, or file transfers, etc..
> 
> thanks,
> Bernard

To complement the other replies, here is a bit more technical background:

In an operating system, running programs are called processes. Each process has access to a block of memory, and it has some running code. For any one process, its running code has the rights to access any part of its memory. However, unless explicitly allowed, it cannot access other process' memory.

If an IM-client process includes openssl code (not for OTR but e.g. to support other protocols), an attacker can cause the bad heartbleed code to be run so that it reads OTR's private data, assuming it is stored in the same process. This is the case for libotr - when a program "uses libotr", this usually means "it loads libotr code into the process".

One can imagine designs where different data are stored in different sub-processes. This is what some programs do, like qmail. And I believe this is one of the reasons why GPG doesn't bother implementing a more flexible interface than the CLI. It's quite awkward to do though, but potentially libotr could follow this route, at some significant engineering cost.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20140416/b7d8659d/attachment.pgp>