Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96574
Return-Path: <smalyshev@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 11273 invoked from network); 24 Oct 2016 05:23:13 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 24 Oct 2016 05:23:13 -0000
Authentication-Results: pb1.pair.com smtp.mail=smalyshev@gmail.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=smalyshev@gmail.com; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.180 as permitted sender)
X-PHP-List-Original-Sender: smalyshev@gmail.com
X-Host-Fingerprint: 209.85.192.180 mail-pf0-f180.google.com  
Received: from [209.85.192.180] ([209.85.192.180:34836] helo=mail-pf0-f180.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 0B/66-28528-FBA9D085 for <internals@lists.php.net>; Mon, 24 Oct 2016 01:23:12 -0400
Received: by mail-pf0-f180.google.com with SMTP id s8so91609641pfj.2
        for <internals@lists.php.net>; Sun, 23 Oct 2016 22:23:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=to:cc:from:subject:message-id:date:user-agent:mime-version
         :content-transfer-encoding;
        bh=7gudl++X8Bs+wjFdH2QPViiN5dMSPwxHlEuKdA/aOgY=;
        b=wguB3lGlNp+d23ux+v/huEHkxRGWmOGWYhAm3f9s7MAfuDRsGBsD2yjTZfMeXutknb
         eZ9DGJphPl9Z9BuebJwkbYdZvl265aHKJVwEI9vtGxefz5ZTTsoxIYDDo350zRfUTiaF
         F7m4VUHB9nEwJJlb6SwfwGfnXkvYt/hvfYgWvcn73qNCgAlTKZDCaIFTeHebZ6Qi1KAX
         /HaGwIrsqJLKDhBVq9XHdTg+KYqaHTw4MrU4VUaxR0rtQGanPJMQpNZTFHnX6gpUkwSO
         e+mHqpQbgyUHaReSPJTMCHkdYdogwqhF0Iwh9Stea/vTr/1pDjehGHWNt5JY3GQtIqVK
         uMmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent
         :mime-version:content-transfer-encoding;
        bh=7gudl++X8Bs+wjFdH2QPViiN5dMSPwxHlEuKdA/aOgY=;
        b=jBlEPLl3z8ezqsypOg0qXztQ9vCokfmmFGVOz8VzCvrRR00SKReR3m1fjpdFIeKhp1
         V/qrTy/0lGkNakXiHIc505DQyJ0e5YEHwQSyQLEzfN0/gVRp4aeo3pZt/9WKVt7qwlv/
         2v3YOXnnzZF0SWxEjT9pdiav3NydEuMA5QzgmwhE8FTSYAYsAtzSr0DVAMrsLVXEvEYT
         bi9a/8uJC6ZnbdRyeXGe5By93Bqy4U3owoMYz55T2OaHfwPQrBo08MqfIkpRU+SOGg5l
         ATBXANtGRMTwd875uVRGSlRTF+4CJF9FJkJcASfhjhgv5sv5ntE0sJ0pE/Ji2+zj0mxr
         VfYw==
X-Gm-Message-State: ABUngvcplhQk0VlXuh5cV2t4lFQpqhlMhrseJhjVDcdPxYNgdusvkxGeeFoQZuWpwm/kFw==
X-Received: by 10.98.86.139 with SMTP id h11mr25473827pfj.73.1477286588098;
        Sun, 23 Oct 2016 22:23:08 -0700 (PDT)
Received: from Stas-Air.local ([2602:306:ce9c:e680:1890:46a7:9aa1:a4af])
        by smtp.gmail.com with ESMTPSA id 3sm21360926pfo.31.2016.10.23.22.23.07
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 23 Oct 2016 22:23:07 -0700 (PDT)
To: PHP Internals <internals@lists.php.net>
Cc: Remi Collet <remi@fedoraproject.org>
Message-ID: <1ae4bea0-d62b-fd61-f6b6-55762e97df6e@gmail.com>
Date: Sun, 23 Oct 2016 22:23:06 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: bug classification discussion
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

We have had a bunch of bugs recently which are essentially one and the
same issue: PHP 5.6 allows only int-sized strings, but many functions
don't check the size of the string they produce. This can lead to int
overflows inside php and also can break other libraries that also assume
string sizes are ints and this can cause all kinds of weirdness.
However, these bugs are very unlikely to manifest in production setting
for one simple reason - they require PHP to run with no memory limit,
and I haven't seen many setups that run with no memory limit. I'm not
going to go into specifics here, since some of the issues are still not
fixed, but you can talk to me privately if you need examples or browse
changelogs of later 5.6 releases.

A twin brother of this is in 7.0 where there are just integer overflows
in string size calculations. Usually that requires huge strings as
inputs, so also requires running with no memory limit.

These bugs are now treated as security issues, due to the fact that in
theory somebody might be running with no memory limit and get huge
string as an input from user. However, it was questioned that we indeed
should treat them so, due to the fact that encountering them in
production is unlikely, and due to the fact that they require patching
in many places, and merging those fixes out-of-band creates significant
potential for bugs.

I'd like to hear feedback on this, especially - though definitely not
only! - from RMs and distro people.

There are some libraries (ICU, I'm looking at you!) which have much
lower limits and fixed buffers inside and unfortunately they don't
enforce or check those limits, they just kind of assume everybody is
nice. For those, I think we'd have to treat issues stemming from that as
security issues if they look exploitable. Also, some libraries have int
overflows independent of PHP (also needing huge strings to trigger) -
not sure what to do with those.

Would be glad to hear some discussion on this.
-- 
Stas Malyshev
smalyshev@gmail.com