Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:54271 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96720 invoked from network); 1 Aug 2011 00:24:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Aug 2011 00:24:33 -0000 Authentication-Results: pb1.pair.com smtp.mail=solar@openwall.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=solar@openwall.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain openwall.com designates 195.42.179.200 as permitted sender) X-PHP-List-Original-Sender: solar@openwall.com X-Host-Fingerprint: 195.42.179.200 mother.openwall.net Received: from [195.42.179.200] ([195.42.179.200:47200] helo=mother.openwall.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 03/3B-24421-042F53E4 for ; Sun, 31 Jul 2011 20:24:33 -0400 Received: (qmail 23563 invoked from network); 1 Aug 2011 00:24:29 -0000 Received: from localhost (HELO pvt.openwall.com) (127.0.0.1) by localhost with SMTP; 1 Aug 2011 00:24:29 -0000 Received: by pvt.openwall.com (Postfix, from userid 503) id A237C2FD28; Mon, 1 Aug 2011 04:24:22 +0400 (MSD) Date: Mon, 1 Aug 2011 04:24:22 +0400 To: Stas Malyshev , Pierre Joye Cc: PHP Internals List Message-ID: <20110801002422.GA23965@openwall.com> References: <20110719234406.GB28946@openwall.com> <4E35CC70.1050203@sugarcrm.com> <20110731223327.GA23361@openwall.com> <20110731225429.GA23508@openwall.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110731225429.GA23508@openwall.com> User-Agent: Mutt/1.4.2.3i Subject: Re: [PHP-DEV] CRYPT_SHA256 fails tests in trunk From: solar@openwall.com (Solar Designer) On Mon, Aug 01, 2011 at 02:54:29AM +0400, Solar Designer wrote: > On Mon, Aug 01, 2011 at 02:33:27AM +0400, Solar Designer wrote: > > On Sun, Jul 31, 2011 at 02:43:12PM -0700, Stas Malyshev wrote: > > > The change that introduced this problem is: > > > http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/standard/crypt_sha256.c?r1=300427&r2=312952 > > > > Now that I look at this, I think there are more problems around this > > place in the code: > > > > 1. Pierre's commit that inadvertently introduced the truncation was a > > bugfix, adding the previously missed NUL termination of the copied salt. > > However, the similar piece of code copying the key appears to still lack > > the NUL termination (it works by pure luck). > > Upon a closer look, the NUL termination might not be needed - neither > for the key nor for the salt. Ulrich Drepper's reference implementation > similarly does not NUL-terminate these, and does not appear to rely on > NUL termination in further code. Has the code in PHP somehow deviated > from this convention? > > Pierre - what was the reason for your commit? > > ...Oh, I think I see the problem: __php_stpncpy() is not sufficiently > correct. It starts by calling strlen(src). Maybe fixing it to more > closely match the real thing would be a cleaner fix? I'm sorry, I misattributed the commit. It was by Ilia, "Fixed bug relating to un-initialized memory access". So I guess it was about the strlen(), unless there's another place accessing beyond salt_len as well. Alexander