On 20 June 2017 at 16:22, Ed Maste <emaste at freebsd.org> wrote:> On 20 June 2017 at 04:13, Vladimir Terziev <vterziev at gvcgroup.com> wrote: >> Hi, >> >> I assume FreeBSD security team is already aware about the Stack Clash vulnerability, that is stated to affect FreeBSD amongst other Unix-like OS. > > Yes, the security team is aware of this. Improvements in stack > handling are in progress (currently in review).I would like to provide some additional background on this issue. First I'd like to thank Qualys for their detailed and thorough investigation, which is contributing directly to improving FreeBSD. The FreeBSD security team is aware of and is monitoring this issue, but is not directly developing in the changes that are in progress. The issue under discussion is a limitation in a vulnerability mitigation technique. Changes to improve the way FreeBSD manages stack growth, and mitigate the issue demonstrated by Qualys' proof-of-concept code, are in progress by FreeBSD developers knowledgeable in the VM subsystem. 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. -Ed
Ed Maste wrote:> On 20 June 2017 at 16:22, Ed Maste <emaste at freebsd.org> wrote: >> On 20 June 2017 at 04:13, Vladimir Terziev <vterziev at gvcgroup.com> wrote: >>> Hi, >>> >>> I assume FreeBSD security team is already aware about the Stack Clash vulnerability, that is stated to affect FreeBSD amongst other Unix-like OS. >> Yes, the security team is aware of this. Improvements in stack >> handling are in progress (currently in review). > I would like to provide some additional background on this issue. > First I'd like to thank Qualys for their detailed and thorough > investigation, which is contributing directly to improving FreeBSD. > > The FreeBSD security team is aware of and is monitoring this issue, > but is not directly developing in the changes that are in progress. > The issue under discussion is a limitation in a vulnerability > mitigation technique. Changes to improve the way FreeBSD manages stack > growth, and mitigate the issue demonstrated by Qualys' > proof-of-concept code, are in progress by FreeBSD developers > knowledgeable in the VM subsystem. 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.One would hope considering the nature and potential threat this would be one of those fixes back ported to previous -STABLE trees as well. -- Michelle Sullivan http://www.mhix.org/
On 21 June 2017 at 20:22, Ed Maste <emaste at freebsd.org> 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
Ed Maste wrote:> On 21 June 2017 at 20:22, Ed Maste <emaste at freebsd.org> 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 at 10amd64 /usr/home/michelle]$ ulimit -Hv 34896609280 [michelle at 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 at 10amd64 /usr/home/michelle]$ time ./CVE-2017-1085 died in main: 49 real 45m3.659s user 3m45.577s sys 41m14.028s [michelle at 10amd64 /usr/home/michelle]$ time ./fgpu Segmentation fault: 11 real 49m1.494s user 2m38.926s sys 46m17.542s [michelle at 10amd64 /usr/home/michelle]$ time ./fgpe died in alloc: 38 real 46m9.318s user 2m25.527s sys 43m38.170s [michelle at 10amd64 /usr/home/michelle]$ Same system only 'exploited' when 'unlimited' as follows: [michelle at 10amd64 /usr/home/michelle]$ ./fgpe char at 0x7ffff4297000: 41; final dist 34998 (198609078) [michelle at 10amd64 /usr/home/michelle]$ ./fgpu char at 0x7ffffffde000: 41 Though the 'CVE-2017-1085' only seg faulted... [michelle at 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/