Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96059 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44309 invoked from network); 21 Sep 2016 14:05:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Sep 2016 14:05:44 -0000 Authentication-Results: pb1.pair.com header.from=fsb@thefsb.org; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=fsb@thefsb.org; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain thefsb.org designates 173.203.187.107 as permitted sender) X-PHP-List-Original-Sender: fsb@thefsb.org X-Host-Fingerprint: 173.203.187.107 smtp107.iad3a.emailsrvr.com Received: from [173.203.187.107] ([173.203.187.107:46225] helo=smtp107.iad3a.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 35/36-04117-7B392E75 for ; Wed, 21 Sep 2016 10:05:44 -0400 Received: from smtp14.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 92CF06053B; Wed, 21 Sep 2016 10:05:41 -0400 (EDT) X-Auth-ID: fsb@thefsb.org Received: by smtp14.relay.iad3a.emailsrvr.com (Authenticated sender: fsb-AT-thefsb.org) with ESMTPSA id 6E32A60544; Wed, 21 Sep 2016 10:05:41 -0400 (EDT) X-Sender-Id: fsb@thefsb.org Received: from yossy.local (c-66-30-62-12.hsd1.ma.comcast.net [66.30.62.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:587 (trex/5.7.7); Wed, 21 Sep 2016 10:05:41 -0400 To: Rowan Collins , PHP Internals References: <7d5727ba-da33-e3c5-1d1f-318c45d81616@cubiclesoft.com> <9522ebc9-8d8b-045e-b701-02f1166063e6@gmail.com> <40868951-8BDA-4860-884C-B8252C1839E3@gmail.com> Message-ID: Date: Wed, 21 Sep 2016 10:05:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <40868951-8BDA-4860-884C-B8252C1839E3@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] HashDoS From: fsb@thefsb.org (Tom Worster) On 9/21/16 8:37 AM, Rowan Collins wrote: > 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. Right. It seems like count-and-limit pushes the problem onto the user who then has to discriminate normal from malicious causes for rising counters and find appropriate actions for each. Even a sophisticated user who understands hash collision counters may not welcome this since it adds complexity that's hard to test and involves questionable heuristics. Tom