Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96044 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11235 invoked from network); 21 Sep 2016 08:06:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Sep 2016 08:06:31 -0000 Authentication-Results: pb1.pair.com smtp.mail=me@kelunik.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=me@kelunik.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.217 cause and error) X-PHP-List-Original-Sender: me@kelunik.com X-Host-Fingerprint: 81.169.146.217 mo4-p00-ob.smtp.rzone.de Received: from [81.169.146.217] ([81.169.146.217:31249] helo=mo4-p00-ob.smtp.rzone.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CA/80-04117-58F32E75 for ; Wed, 21 Sep 2016 04:06:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1474445186; l=6275; s=domk; d=kelunik.com; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=+O1tzylBdWnqstl7GBJHIxXwj7bXpl0KFPhCuVSAdwc=; b=f3Gzd3x2s5Mpj3H2KpgI78o48anOvtyDMT9oOmXP2VJ7U0ueY6ISyTqL0boWbKgKqZJ 3A8/KtP9pD83atZTTbshHJzNgAkstILZSRdeIsEWjLfnR0P2Eo9DkAmb25gHI4QO6BCs+ L9tQjPdOMwQ3t39+hbIpN8x+TNegVbFkCes= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLGvomb4bl9EfHtOnI6 X-RZG-CLASS-ID: mo00 Received: from mail-wm0-f51.google.com ([74.125.82.51]) by smtp.strato.de (RZmta 39.2 AUTH) with ESMTPSA id d08dcas8L86QY6A (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 10:06:26 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id l132so252698082wmf.0 for ; Wed, 21 Sep 2016 01:06:26 -0700 (PDT) X-Gm-Message-State: AE9vXwNgFD81c53et5XHlZ/H3flqy1pBlqGaIi93r4MTfJHD9jY9lw+Ma/ZKaxQI3SIMBWjvSzLHtq1Njl8IxQ== X-Received: by 10.194.51.138 with SMTP id k10mr29887768wjo.126.1474445186355; Wed, 21 Sep 2016 01:06:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.125.132 with HTTP; Wed, 21 Sep 2016 01:06:25 -0700 (PDT) In-Reply-To: References: <7d5727ba-da33-e3c5-1d1f-318c45d81616@cubiclesoft.com> <9522ebc9-8d8b-045e-b701-02f1166063e6@gmail.com> Date: Wed, 21 Sep 2016 10:06:25 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Yasuo Ohgaki Cc: Stanislav Malyshev , Scott Arciszewski , Thomas Hruska , PHP Internals Content-Type: multipart/alternative; boundary=bcaec50b519492e000053d000596 Subject: Re: [PHP-DEV] HashDoS From: me@kelunik.com (Niklas Keller) --bcaec50b519492e000053d000596 Content-Type: text/plain; charset=UTF-8 2016-09-21 8:54 GMT+02:00 Yasuo Ohgaki : > Hi Stas, > > On Wed, Sep 21, 2016 at 11:26 AM, Stanislav Malyshev > wrote: > > > >> I think we are better to limit max collisions. > >> I'm +1 for Nikita's proposal does this. > > > > Max collision per what? How much would be the limit? > > Collision by keys. > > It would be nice to have configurable limit like regex stack/backtrack > limit. > That said, wouldn't 1000 enough for almost all apps? > Having a limit isn't a good idea for all use cases, but it works for some. > Anyway, we have two choices > - Simply limit the number of collisions. (Fast and has no impact to code) > It totally has impact to code. What happens if we have enough collisions? Throw an exception? Might break code, any array insert operation might suddenly fail. Simply fatal? Not suitable for long running applications like Aerys (https://github.com/amphp/aerys) or PPM ( https://github.com/php-pm/php-pm). I guess to support these use cases, we have to switch to a cryptographic hash function here. But I guess it would be totally fine having such a feature as compile flag, limiting the number of collisions usually and provide a cryptographic hash function for long running apps to protect them. I think such an option is fine for those running long running applications, since they don't rely on setups like shared hosting and can usually compile their own versions. > - Use crypt safe hash and salt. (Slow and has impact to opcache/etc) > Do we need a salt here? If not, how does it then impact opcache? > Limiting something is good to have sometimes. > Python even limits number of recursions to 1000 by default. > Recursion is / should not be affected by user input and thus is a slightly different topic. Regards, Niklas > We have PCRE stack/backtrack limits. (We'll have mbregex stack limit soon) > Collision limit is good one also. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --bcaec50b519492e000053d000596--