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  and my original gentoo bug report is here . 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  http://git.savannah.gnu.org/gitweb/?p=weechat.git;a=commitdiff;h=c324610226cef15ecfb1235113c8243b068084c8;hp=f821a94cc412bc4afc7fc751cf040e88603c6b98#patch3  https://bugs.gentoo.org/show_bug.cgi?id=501078
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ