[OTR-users] OTR and OpenSSL Heartbleed vulnerability?

[Ximin Luo]

On 16/04/14 22:37, Bernard Tyers - ei8fdb wrote:
> 
> On 16 Apr 2014, at 22:29, Ximin Luo <infinity0 at pwned.gg> wrote:
> 
>> To complement the other replies, here is a bit more technical background:
>>
>> 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".
> 
> Thanks for the explanation. Like I mentioned would the OTR secret keys be identifiable as such, or would it be “something that looked like a secret key”?
> 

It depends, either is possible - one can read the libotr source code and see if a key contains any identifying markers (likely), or even if not, just a block of allocated memory (with some predictable bookkeeping data that surrounds it) where the contents have high entropy, could be collected and tested later (e.g. to see if it decrypts something).

>> One can imagine designs where different data are stored in different sub-processes. 
> 
> Hence, Daniel’s mention of “an out-of-process cryptographic agent” I presume?
> 

Yes.

>>  It’s quite awkward to do though, but potentially libotr could follow this route, at some significant engineering cost.
> 
> Is it likely that this seperation of cryptographic processes is needed for forseeable security issues? Asked another way (he says with his tongue in his cheek) is an exploit like this Heartbleed likely to occur again?
> 

Process separation would be a conceptual improvement. However, doing it cross platform is awkward (basically, restrict yourself to stdin/stdout, no signals since they are only intra-process on windows), and if not done right, it may itself open up security holes. I do somewhat agree with Timo's view that it's not *that* high a cost, but well, someone still needs to find the motivation to do it. :)

Another thing is, the fact that all code within a process has access rights to all of its memory, is arguably not the most secure design. This would be a topic for OS research though.

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/62bd6e0e/attachment.pgp>