From mboxrd@z Thu Jan  1 00:00:00 1970
From: Danny Milosavljevic <dannym@scratchpost.org>
Subject: bug#27429: Stack clash (CVE-2017-1000366 etc); -fstack-check
Date: Sun, 25 Jun 2017 11:38:28 +0200
Message-ID: <20170625113828.024a425f@scratchpost.org>
References: <20170619222550.GA29289@jasmine.lan>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-path: <bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33618)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1dP40X-0002FD-W0
	for bug-guix@gnu.org; Sun, 25 Jun 2017 05:39:07 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1dP40U-0001CE-NP
	for bug-guix@gnu.org; Sun, 25 Jun 2017 05:39:06 -0400
Received: from debbugs.gnu.org ([208.118.235.43]:33634)
	by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
	(Exim 4.71) (envelope-from <Debian-debbugs@debbugs.gnu.org>)
	id 1dP40U-0001C6-JD
	for bug-guix@gnu.org; Sun, 25 Jun 2017 05:39:02 -0400
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-Message-ID: <handler.27429.B27429.149838351626211@debbugs.gnu.org>
In-Reply-To: <20170619222550.GA29289@jasmine.lan>
List-Id: Bug reports for GNU Guix <bug-guix.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-guix>,
	<mailto:bug-guix-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/bug-guix/>
List-Post: <mailto:bug-guix@gnu.org>
List-Help: <mailto:bug-guix-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-guix>,
	<mailto:bug-guix-request@gnu.org?subject=subscribe>
Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org
Sender: "bug-Guix" <bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org>
To: 27429@debbugs.gnu.org

Hi,

what do you all think of rebuilding the world with "-fstack-check" (either now or later on) ?

That would make gcc emit code to always grow the stack in a way that it certainly touches each 4 KiB (parametrizable by STACK_CHECK_PROBE_INTERVAL_EXP) page on the way.

I think that would be the right and permanent fix - unlike the whack-a-mole approach where we patch programs not to do what they are supposed to do, if their stack allocation happens to grow.

See also <https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt> and <https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html>.

Note that the kernel itself has to put argv and envp into the user process' stack and this can already make the very first stack allocation that a process does in its main() need to grow the stack, and reach across the guard page.  So the right fix is to just make the stack allocations never reach across the guard page without using it.