oss-security - Possible CVE Request for Weechat -- Mutex potentially not held for random number generation

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAHmME9qFxSkLYp1w2FUPU5rELJCbAacWGRdV2VPRMxE3w890HA@mail.gmail.com>
Date: Thu, 13 Feb 2014 16:48:07 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: oss-security <oss-security@...ts.openwall.com>
Cc: weechat-dev@...gnu.org
Subject: Possible CVE Request for Weechat -- Mutex potentially not held for
 random number generation

Hey folks,

I've just fixed a bit of an odd bug in Weechat, that may or may not be
security-related in certain circumstances, and I was hoping to have
some other eyeballs take a poke at it. The patch for it is here [1]
and my original gentoo bug report is here [2].

The basic problem is that Weechat did not link against libpthread on
Linux. However, gnutls uses libpthread. The glibc developers were
clever and set things up such that if you don't explicitly link
against libpthread, and library code still uses the functions from it,
you'll instead wind up using functions that all return 0. This is so
that single-threaded programs aren't burdened with the overhead of
mutexes and such, when they aren't needed. So when weechat was loaded,
it would also load gnutls. Gnutls would then make several calls to
pthread_mutex_init. Since libpthread wasn't loaded, this function
would be hitting the code inside libc, which would simply return 0. So
the mutex would never be initialized and instead it would contain
uninitialized junk from malloc(). This was fine, since all the other
pthread functions that libc implements do the same - return 0 - so
nothing bad happens since that data is never touched. However, later
in the weechat initialization, the various plugins are loaded. Some
plugins directly or indirectly link the proper libpthread. This means
that after this point, all function calls to pthread_mutex_lock and
pthread_mutex_unlock are hitting the real pthread code, that actually
works with the data and does a lot more than simply return 0. But
because these mutexes were not initialized before with the
zero-returning pthread_mutex_init, the lock and unlock functions are
dealing with uninitialized random malloc() data. And so, in lots of
cases, we crash, or abort().

So I guess there could be an issue in cases in which this doesn't
crash -- when malloc() returns zeros; this seems to be happening on
some machines. In that case, weechat runs fine, but if any other
threads use gnutls, a mutex isn't kept for the random number
generator. I haven't had time to analyze lib/nettle/rnd.c -- this is
what I was hoping to receive some help with -- but I suppose there's
potential for the lack of a working mutex to result in degraded random
number generation security. But maybe not. I'm not sure.

Thanks,
Jason

[1] http://git.savannah.gnu.org/gitweb/?p=weechat.git;a=commitdiff;h=c324610226cef15ecfb1235113c8243b068084c8;hp=f821a94cc412bc4afc7fc751cf040e88603c6b98#patch3
[2] https://bugs.gentoo.org/show_bug.cgi?id=501078

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.