GitLab

There is a uninitialized variable problem in libotr's implementation of SMP, the worst case outcome would be an arbitrary free leading to remote code execution on the machine of a willing participant in SMP (i.e. the bug occurs after pidgin-otr UI interactions for SMP), but I'd consider this to be a pretty unlikely attack. Still, its probably worth fixing this and keeping an eye out for similar patterns in the future (there are a few other near misses).

In message.c on line 1514, the sendsmp pointer is passed in uninitialized to otrl_proto_create_data. The assumption is that otrl_proto_create_data will allocate memory and store the resulting pointer in sendsmp. However, there is a failure case under memory pressure in otrl_proto_create_data that occurs before the encmessagep output pointer is initialized. If gcry_malloc_secure returns NULL, then otrl_proto_create_data will immediately return GPG_ERR_ENOMEM. At this point the following code is run:

char sendsmp; ... / line 1514 of message.c */ err = otrl_proto_create_data(&sendsmp, context, "", sendtlv, OTRL_MSGFLAGS_IGNORE_UNREADABLE, NULL);

if (!err) { /* condition is not met since otrl_proto_create_data returned an error */ err = fragment_and_send(ops, opdata, context, sendsmp, OTRL_FRAGMENT_SEND_ALL, NULL); }

/* sendsmp is uninitialized */ free(sendsmp); ...

The exact value of sendsmp will depend on the alignment of the current stack frame over previous stack frames. In the worst case scenario, this could result in an attacker controlled value being freed.

Note that otrl_proto_create_data's earlier failure case on context->msgstate or context->context_priv->their_keyid is not a viable option to trigger this bug, as sending OTRL_TLV_DISCONNECTED means that context->smstate->nextExpected is reset.

(from redmine: created on 2014-11-29, closed on 2015-12-29)