Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96053 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34845 invoked from network); 21 Sep 2016 13:23:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Sep 2016 13:23:06 -0000 Authentication-Results: pb1.pair.com header.from=me@kelunik.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=me@kelunik.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.216 cause and error) X-PHP-List-Original-Sender: me@kelunik.com X-Host-Fingerprint: 81.169.146.216 mo4-p00-ob.smtp.rzone.de Received: from [81.169.146.216] ([81.169.146.216:25725] helo=mo4-p00-ob.smtp.rzone.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E7/34-04117-1B982E75 for ; Wed, 21 Sep 2016 09:23:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1474464174; l=3218; s=domk; d=kelunik.com; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=VBG8L9CjAmU739RGI5Lgdgq62XYKEYqHL9l584Y7d1M=; b=pjlifLQ85exucAVXm57j4ZPnXRqtkxRIl889v3cGxLYfr+Zxmbz46Rp1R34BAxgHCOC Xjf1e7ZeOMT9t/dU5LvacuFjIqUCGTGNj/Jhlid93Q2uXhPQZK0BBqC+lgmL1jxzTmKD6 f5X4h8cC+JwAqBTy1lIZ8VoRQrEyTxVs7og= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLGvomb4bl9EfHtO3o6 X-RZG-CLASS-ID: mo00 Received: from mail-wm0-f49.google.com ([74.125.82.49]) by smtp.strato.de (RZmta 39.2 AUTH) with ESMTPSA id 6049d8s8LDMsaE1 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client did not present a certificate) for ; Wed, 21 Sep 2016 15:22:54 +0200 (CEST) Received: by mail-wm0-f49.google.com with SMTP id l132so91529117wmf.1 for ; Wed, 21 Sep 2016 06:22:54 -0700 (PDT) X-Gm-Message-State: AE9vXwNBdhW+jC1uFTYS+GWwODtHLrDIOQRnuHgRHIpTP+BOuLT6OiwIeZ7VoZIask6CyYrZtsX76l7sQJUKkQ== X-Received: by 10.28.39.134 with SMTP id n128mr3365794wmn.60.1474464174251; Wed, 21 Sep 2016 06:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.125.132 with HTTP; Wed, 21 Sep 2016 06:22:53 -0700 (PDT) In-Reply-To: <40868951-8BDA-4860-884C-B8252C1839E3@gmail.com> References: <7d5727ba-da33-e3c5-1d1f-318c45d81616@cubiclesoft.com> <9522ebc9-8d8b-045e-b701-02f1166063e6@gmail.com> <40868951-8BDA-4860-884C-B8252C1839E3@gmail.com> Date: Wed, 21 Sep 2016 15:22:53 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Rowan Collins Cc: PHP Internals Content-Type: multipart/alternative; boundary=001a114e2126579d61053d0471db Subject: Re: [PHP-DEV] HashDoS From: me@kelunik.com (Niklas Keller) --001a114e2126579d61053d0471db Content-Type: text/plain; charset=UTF-8 2016-09-21 14:37 GMT+02:00 Rowan Collins : > On 21 September 2016 13:02:20 BST, Glenn Eggleton > wrote: > >What if we had some sort of configuration limit on collision length? > > Previous discussions have come to the conclusion that the difference > between normal collision frequency and sufficient for a DoS is so large > that the only meaningful settings would be on or off. e.g. the proposed > limit is 1000, and randomly inserting millions of rows produces about 12. > > The problem with long running applications is not that they need to raise > the limit, it's that they need to handle the error gracefully if they are > in fact under attack. Because hash tables are so ubiquitous in the engine, > there's no guarantee that that's possible, so an attacker would have the > ability to crash the process with the limit turned on, or hang the CPU with > the limit turned off. Another suggestion by Markus Staab is to move the code into the SAPIs and have SipHash in CLI and the current hash function in e.g. Apache's SAPI. Since long running applications use only the CLI, it would be fine for them and it wouldn't even need a compile flag. Regards, Niklas --001a114e2126579d61053d0471db--