[OTR-users] Security Advisory: upgrade to libotr 4.1.1

Off-the-Record Messaging (OTR) Security Advisory 2016-01 Integer overflow vulnerability in libotr Versions 4.1.0 and earlier of libotr in 64-bit builds contain an integer overflow security flaw. This flaw could potentially be exploited by a remote attacker to cause a heap buffer overflow and subsequently for arbitrary code to be executed on the user's machine. In several places in proto.c, the sizes of portions of incoming messages were stored in variables of type int or unsigned int instead of size_t. If a message arrives with very large sizes (for example unsigned int datalen = UINT_MAX), then constructions like malloc(datalen+1) will turn into malloc(0), which on some architectures returns a non-NULL pointer, but UINT_MAX bytes will get written to that pointer. CVE-2016-2851 has been assigned to this issue. The recommended course of action is to upgrade libotr to version 4.1.1 immediately. The new version can be obtained here: Source code: https://otr.cypherpunks.ca/libotr-4.1.1.tar.gz gpg signature: https://otr.cypherpunks.ca/libotr-4.1.1.tar.gz.asc git repository: git://git.otr.im/libotr.git (tag 4.1.1) A new Windows binary of pidgin-otr (4.0.2) linked to libotr 4.1.1 is available; however, as the Windows version is a 32-bit build, it is not susceptible to the above flaw. Windows users may wish to upgrade in any event in order to take advantages of other fixes in libotr 4.1.1 and pidgin-otr 4.0.2, however (see the respective NEWS files). pidgin-otr 4.0.2 Source code: https://otr.cypherpunks.ca/pidgin-otr-4.0.2.tar.gz gpg signature: https://otr.cypherpunks.ca/pidgin-otr-4.0.2.tar.gz.asc Windows installer: https://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.2.exe gpg signature: https://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.2.exe.asc Windows zip file: https://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.2.zip gpg signature: https://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.2.zip.asc Linux and *BSD vendors and package maintainers have been notified, and updated packages should be available from them. If upgrading to version 4.1.1 is not possible, please apply the following patch to 4.1.0: --- a/src/proto.c +++ b/src/proto.c @@ -715,7 +715,7 @@ gcry_error_t otrl_proto_accept_data(char **plaintextp, OtrlTLV **tlvsp, unsigned int sender_keyid, recipient_keyid; gcry_mpi_t sender_next_y = NULL; unsigned char ctr[8]; - unsigned int datalen, reveallen; + size_t datalen, reveallen; unsigned char *data = NULL; unsigned char *nul = NULL; unsigned char givenmac[20]; @@ -916,7 +916,7 @@ OtrlFragmentResult otrl_proto_fragment_accumulate(char **unfragmessagep, if (k > 0 && n > 0 && k <= n && start > 0 && end > 0 && start < end) { if (k == 1) { - int fraglen = end - start - 1; + size_t fraglen = end - start - 1; size_t newsize = fraglen + 1; free(context->context_priv->fragment); context->context_priv->fragment = NULL; @@ -937,7 +937,7 @@ OtrlFragmentResult otrl_proto_fragment_accumulate(char **unfragmessagep, } } else if (n == context->context_priv->fragment_n && k == context->context_priv->fragment_k + 1) { - int fraglen = end - start - 1; + size_t fraglen = end - start - 1; char *newfrag = NULL; size_t newsize = context->context_priv->fragment_len + fraglen + 1; /* Check for overflow */ @@ -989,10 +989,10 @@ gcry_error_t otrl_proto_fragment_create(int mms, int fragment_count, char ***fragments, ConnContext *context, const char *message) { char *fragdata; - int fragdatalen = 0; + size_t fragdatalen = 0; int curfrag = 0; - int index = 0; - int msglen = strlen(message); + size_t index = 0; + size_t msglen = strlen(message); /* Should vary by number of msgs */ int headerlen = context->protocol_version == 3 ? 37 : 19; @@ -1012,7 +1012,7 @@ gcry_error_t otrl_proto_fragment_create(int mms, int fragment_count, int i; char *fragmentmsg; - if (msglen - index < mms - headerlen) { + if (msglen - index < (size_t)(mms - headerlen)) { fragdatalen = msglen - index; } else { fragdatalen = mms - headerlen; Our heartfelt thanks to Markus Vervier of X41 D-Sec GmbH <markus.vervier at x41-dsec.de> for finding and alerting us to this flaw. Followups to the otr-users mailing list <otr-users at lists.cypherpunks.ca>, please. Thanks, Ian Goldberg <iang at cs.uwaterloo.ca> for the OTR development team <otr at cypherpunks.ca>