From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,SPF_PASS, T_DKIM_INVALID shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 070D820357 for ; Mon, 17 Jul 2017 16:12:24 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 4C5AE12077C; Tue, 18 Jul 2017 01:12:21 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 27ADD120751 for ; Tue, 18 Jul 2017 01:12:18 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=SEMz7aSVGp10KLAYDt+tQ0rC1uo=; b=Yok0JGMCgpA3s3jhbA O/CBcKBcKLikXjiPA1DkRv/vwUVH6EH0A3L0WnOmtrx2XJzAa9kK/85BYhosz+GQ C58NtIJ0AfiNKSeVTKVDbYRVy1qSVciXOHAePo40rGUMrnSUeCV6+b12DoQO4T+S Dccpn5bOFO81qeRy7cre9PaqU= Received: by filter0830p1mdw1.sendgrid.net with SMTP id filter0830p1mdw1-20763-596CE1C3-38 2017-07-17 16:11:47.312934098 +0000 UTC Received: from herokuapp.com (ec2-54-92-141-89.compute-1.amazonaws.com [54.92.141.89]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id DHtZpRfaSRSeCCssSBgauw for ; Mon, 17 Jul 2017 16:11:47.210 +0000 (UTC) Date: Mon, 17 Jul 2017 16:11:58 +0000 (UTC) From: eregontp@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 57127 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 13660 X-Redmine-Issue-Author: Eregon X-Redmine-Sender: Eregon X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS5pZ6sT5L12AAsGxjVbDLqar0FjykKaWl3ZKU XGOXO7mRnNimvH6glOzZQqY4ZOCBpsluQWxOotzZkeZwxeO5AyxonRQUFdOAWGI2DGC9ffqD6CP83S CPIBYvR0aNBx8YRWwmmOmDmj9DR6q37mK4cSS8toUsBNm9jD0ipj0hx5UQ== X-ML-Name: ruby-core X-Mail-Count: 82089 Subject: [ruby-core:82089] [Ruby trunk Bug#13660] rb_str_hash_m discards bits from the hash X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #13660 has been updated by Eregon (Benoit Daloze). I think the case where half the bits are lost could become a potential security issue. Essentially all strings which have the same first half will collide in a Hash, and that's likely trivial to generate (the same prefix/suffix of the right length is likely to generate the same half). In that case (sizeof(long) < sizeof(void*)), I think at least the two parts should be combined with something like (long)(value ^ (value >> 32)). But I am not a security expert. ---------------------------------------- Bug #13660: rb_str_hash_m discards bits from the hash https://bugs.ruby-lang.org/issues/13660#change-65820 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.3.3p222 (2016-11-21 revision 56859) [x64-mingw32] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- I believe rb_str_hash_m might discard some bits from the hash value in some situations. It computes the hash as a st_index_t, which is either a unsigned long or a unsigned long long. But the st_index_t value is converted to a VALUE with: #define ST2FIX(h) LONG2FIX((long)(h)) Note that for instance on x64-mingw32, SIZEOF_LONG is 4, but SIZEOF_LONG_LONG and SIZEOF_VOIDP are 8 bytes. So that truncates half the bits of the hash on such a platform if my understanding is correct. Even is SIZEOF_LONG is 8, LONG2FIX loses the MSB I think, given that not all long can fit the Fixnum range on MRI (should it be LONG2NUM?). Also, I am not sure if it is intended to cast from a unsigned value to a signed value. I tried many things while debugging the rb_str_hash spec on ruby/spec and eventually gave up. This computation looks wrong to me in MRI. For info, here is my debug code: https://github.com/eregon/rubyspec/blob/d62189450c0a56bfcd379e5e505ad097892d2bc7/optional/capi/string_spec.rb#L501-L518 https://github.com/eregon/rubyspec/blob/d62189450c0a56bfcd379e5e505ad097892d2bc7/optional/capi/ext/string_spec.c#L361-L381 and the build result on AppVeyor: https://ci.appveyor.com/project/eregon/spec-x948i/build/629 -- https://bugs.ruby-lang.org/