From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 22942BC57 for ; Fri, 9 Jul 2010 02:59:44 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0GADIRNkxQW+UMgWdsb2JhbACDHpBXjD8VAQEWIiKvHJEpgSmDCnIEiEI X-IronPort-AV: E=Sophos;i="4.53,561,1272837600"; d="scan'208";a="62984223" Received: from lo.gmane.org ([80.91.229.12]) by mail1-smtp-roc.national.inria.fr with ESMTP; 09 Jul 2010 02:59:43 +0200 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OX1wK-00071C-Nc for caml-list@inria.fr; Fri, 09 Jul 2010 02:59:40 +0200 Received: from bas3-toronto02-1279545582.dsl.bell.ca ([76.68.80.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Jul 2010 02:59:40 +0200 Received: from michael by bas3-toronto02-1279545582.dsl.bell.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Jul 2010 02:59:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Michael Ekstrand Subject: Native code stack overflow detection guarantees Date: Thu, 08 Jul 2010 20:59:30 -0400 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: bas3-toronto02-1279545582.dsl.bell.ca User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Lightning/1.0b1 Thunderbird/3.0.5 X-Enigmail-Version: 1.0.1 X-Spam: no; 0.00; recursive:01 pointer:01 ocaml:01 ocamlopt:01 bytecode:01 compiler:01 bytecode:01 compiler:01 powerpc:01 terminating:01 whereby:01 havoc:98 overflows:01 overflows:01 unix:01 Some time ago, I saw someone mention non-tail-recursive functions in native code as a security problem. Unfortunately, I cannot find where I read that again, but the basic idea was that, if you have a recursive function that uses stack linear in user-provided input, then the user can trigger a stack overflow which, in native code, can allow your stack pointer to go waltzing through memory and wreak general havoc since stack overflows are not trapped. I was attempting to do some further research on this subject today and found section 11.5 in the OCaml manual (ocamlopt compatibility with the bytecode compiler), where it described the stack overflow behavior: * By raising a Stack_overflow exception, like the bytecode compiler does. (IA32/Linux, AMD64/Linux, PowerPC/MacOSX, MS Windows 32-bit ports). * By aborting the program on a “segmentation fault” signal. (All other Unix systems.) * By terminating the program silently. (MS Windows 64 bits). I have also turned up mailing list posts indicating that the stack overflow exception is generated by a sigsegv signal handler on Linux. My goal is to determine whether the ability for user input to cause a stack overflow is merely a denial-of-service vulnerability (they shut down the process, but can't do anything else), or whether it represents an attack vector whereby they could modify memory, execute arbitrary code, or perform other such shenanigans. Therefore, I am wondering: are there documented guarantees on which the native code stack overflow behavior rests? Linux processes usually receive a segmentation fault when they run out of stack space; is that guaranteed, or is it simply the usual convenient behavior? What about for other systems? If the program will always die, either via Stack_overflow or a segmentation fault, as soon as the stack overflow occurs before there is opportunity for more thorough memory corruption, then I think I can take user-triggerable stack overflows to be inconvenient and undesirable but not a viable attack vector other than for DoS attacks. Thank you for any answers or insight you might be able to provide. - Michael