caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Michael Ekstrand <michael@elehack.net>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Native code stack overflow detection guarantees
Date: Sun, 11 Jul 2010 13:03:00 +0200	[thread overview]
Message-ID: <87mxtynuvv.fsf@frosties.localdomain> (raw)
In-Reply-To: <i15s9k$e35$1@dough.gmane.org> (Michael Ekstrand's message of "Thu, 08 Jul 2010 20:59:30 -0400")

Michael Ekstrand <michael@elehack.net> writes:

> 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.

For that to happen you would have to get the stack pointer to overflow
so far that it actualy points into an allocated memory region
again. Stack frames usualy aren't that big and I'm pretty certain there
will be some unallocated space around the stack to catch
overflows. Isn't a stackframe for a recursive call in ocaml limited in
size (<< PAGE_SIZE)? Unless you have some varargs in there.

I don't see any security probem there other than DOS attacks. With an
exception you could catch it and continue running while a segfault kills
your program (usualy). So for native code you would have to inspect your
input and check if it will stack overflow before calling the recursive
function. Or just write the function tail recursive.

MfG
        Goswin


      parent reply	other threads:[~2010-07-11 11:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-09  0:59 Michael Ekstrand
2010-07-09  8:39 ` [Caml-list] " Mark Shinwell
2010-07-09  8:46   ` [Caml-list] Native code stack overflow detection guarantees - followup Mark Shinwell
2010-07-11 11:03 ` Goswin von Brederlow [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mxtynuvv.fsf@frosties.localdomain \
    --to=goswin-v-b@web.de \
    --cc=caml-list@inria.fr \
    --cc=michael@elehack.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).