From owner-freebsd-security@freebsd.org Mon Jul 3 16:29:17 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7AF69EA275 for ; Mon, 3 Jul 2017 16:29:17 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (hades.sorbs.net [72.12.213.40]) by mx1.freebsd.org (Postfix) with ESMTP id AAC5976929; Mon, 3 Jul 2017 16:29:17 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0OSI0045IWTHYR00@hades.sorbs.net>; Mon, 03 Jul 2017 09:36:55 -0700 (PDT) Subject: Re: The Stack Clash vulnerability To: Ed Maste , "freebsd-security@freebsd.org" References: From: Michelle Sullivan Message-id: <3bca2dbd-dc2f-ca7a-e0ce-eb7d6cf0b3e5@sorbs.net> Date: Mon, 03 Jul 2017 18:29:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 In-reply-to: X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 16:29:17 -0000 Ed Maste wrote: > On 21 June 2017 at 20:22, Ed Maste wrote: >> These changes are expected to be >> committed to FreeBSD soon, and from there they will be merged to >> stable branches and into updates for supported releases. > The changes have now been merged to HEAD in r320317. > https://svnweb.freebsd.org/changeset/base/320317 > _______________________________________________ > Been watching for it in 10-STABLE... didn't see it go in... did I miss it? Regards, Michelle FWIW, been testing on various versions... seems that the Qualsys test code are 3 examples. 'fgpe' and 'fgpu' seem to work on pre-11 under the following senario... ulimit -v is set to unlimited. 'CVE-2017-1085' appears not to work, setting ulimit -v to anything but unlimited seems to break both 'fgpe' and 'fgpu' (to reasonable values I have tested so far).... it also seemed only to work when all virtual memory was exhausted (which made sizable processes and considerable allocation/run times.) Follows is around 32G limit on the vm size (which unless it's one of my DB servers) is about 16 times more than any process should need. [michelle@10amd64 /usr/home/michelle]$ ulimit -Hv 34896609280 [michelle@10amd64 /usr/home/michelle]$ ulimit -a socket buffer size (bytes, -b) unlimited core file size (blocks, -c) unlimited data seg size (kbytes, -d) 33554432 file size (blocks, -f) unlimited max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 294246 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) 524288 cpu time (seconds, -t) unlimited max user processes (-u) 14043 virtual memory (kbytes, -v) 34896609280 swap size (kbytes, -w) unlimited [michelle@10amd64 /usr/home/michelle]$ time ./CVE-2017-1085 died in main: 49 real 45m3.659s user 3m45.577s sys 41m14.028s [michelle@10amd64 /usr/home/michelle]$ time ./fgpu Segmentation fault: 11 real 49m1.494s user 2m38.926s sys 46m17.542s [michelle@10amd64 /usr/home/michelle]$ time ./fgpe died in alloc: 38 real 46m9.318s user 2m25.527s sys 43m38.170s [michelle@10amd64 /usr/home/michelle]$ Same system only 'exploited' when 'unlimited' as follows: [michelle@10amd64 /usr/home/michelle]$ ./fgpe char at 0x7ffff4297000: 41; final dist 34998 (198609078) [michelle@10amd64 /usr/home/michelle]$ ./fgpu char at 0x7ffffffde000: 41 Though the 'CVE-2017-1085' only seg faulted... [michelle@10amd64 /usr/home/michelle]$ ./CVE-2017-1085 Segmentation fault: 11 All amd64 (haven't gotten around to testing i386 yet) Know of any other tests... or are these pretty typical/comprehensive? (being that setting a system wide hard limit of say 32G would seem to work around the issue...) Thanks in advance.. -- Michelle Sullivan http://www.mhix.org/