Re: Avoiding memory access vulnerabilities

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups	comp.lang.forth
Subject	Re: Avoiding memory access vulnerabilities
Date	2016-02-27 07:15 +0000
Organization	Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID	<2016Feb27.081505@mips.complang.tuwien.ac.at> (permalink)
References	<2016Feb26.143842@mips.complang.tuwien.ac.at> <20160226171816.2a1470dc@_>

Show all headers | View raw

Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> writes:
>Buffer overflows work in C because C uses a combined data stack and
>return stack, i.e., stack frame.

No.  Separating the return addresses is not sufficient to preventing
arbitrary code execution.  If return addresses were separate,
attackers would overwrite function pointers.

>  You'd need to ban manipulation of
>the return stack in Forth.

Standard-conforming use of >R, R@, R> are not a danger, because these
values are not used as return values, and there are no buffers on the
return stack.  Bugs involving these words that accidentially treat
data as return addresses are also unlikely in tested programs, because
such bugs cause crashes pretty much every time the code is executed.
I'll leave the analysis of the safety of N>R NR> to fans of these
words.

Concerning (non-standard) return-address manipulations, many people
just drop return addresses; a danger is that what then is returned to
is data, but, as with standard usage of >R R>, this would not survive
testing and debugging.  Another common pattern is that various return
addresses are duped or swapped around; there is no way for data to get
in there, except via a bug, and again, such a bug would be very
obvious in testing and would not survive until production.

One danger would to store such a return address in data space, and
then use it as return address later; this would allow a buffer
overflow vulnerability to overwrite this value and lead to arbitrary
code execution.  But I have never seen that kind of usage, and in any
case, it is not any more of a danger than xts in the dictionary.

One related danger, however, is the address of the last exception
frame; Gforth keeps that in the dictionary, and it is probably not the
only Forth system; if the attacker can change that and cause a taken
THROW (e.g., by sending a signal to the process), he can execute
arbitrary code.  Overwriting some deferred word is probably an easier
attack, though.

>Forth words in the dictionary, while
>they may contain an XT, are not buffers that can be written to
>and overflowed via input and print string functions.

Counterexample:

create buf 100 allot
create two-xts ' . , ' . ,
buf 1000 untrusted-file read-file

>Preventing the
>Forth dictionary from being written to would solve the adjacent XT
>overwrite problem.

It would not solve these problems (see below), but it would prevent
most standard programs from working, because they tend to have at
least some data in data space that they write to.

You can also have a buffer overflow in the heap with an adjacent xt.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

Thread

Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-26 13:38 +0000
  Re: Avoiding memory access vulnerabilities Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-26 16:05 +0000
  Re: Avoiding memory access vulnerabilities Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-26 17:18 -0500
    Re: Avoiding memory access vulnerabilities Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-02-26 22:53 -0800
    Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-27 07:15 +0000
      Re: Avoiding memory access vulnerabilities Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-27 04:54 -0600
      Re: Avoiding memory access vulnerabilities Bernd Paysan <bernd.paysan@gmx.de> - 2016-02-27 14:27 +0000
        Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-27 15:31 +0000
          Re: Avoiding memory access vulnerabilities Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-01 16:30 +0000
            Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-02 10:04 +0000
              Re: Avoiding memory access vulnerabilities Doug Hoffman <glidedog@gmail.com> - 2016-03-02 08:41 -0500
              Re: Avoiding memory access vulnerabilities Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-02 23:22 +0000
                Re: Avoiding memory access vulnerabilities humptydumpty <ouatubi@gmail.com> - 2016-03-02 22:57 -0800
                Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 13:50 +0000
                Re: Avoiding memory access vulnerabilities Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-04 21:01 +0000
                Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-06 10:55 +0000
      Re: Avoiding memory access vulnerabilities Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-02-27 11:31 -0500
        Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-27 17:14 +0000
  Re: Avoiding memory access vulnerabilities Ron Aaron <rambamist@gmail.com> - 2016-02-27 18:59 +0200
    Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-27 17:04 +0000
      Re: Avoiding memory access vulnerabilities Ron Aaron <rambamist@gmail.com> - 2016-02-27 19:18 +0200
        Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-28 14:21 +0000
  Re: Avoiding memory access vulnerabilities "Elizabeth D. Rather" <erather@forth.com> - 2016-03-02 21:18 -1000
    Re: Avoiding memory access vulnerabilities Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-03 10:23 +0000
      Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 14:22 +0000
    Re: Avoiding memory access vulnerabilities Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-03 04:53 -0600
      Re: Avoiding memory access vulnerabilities Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-03 13:15 +0000
        Re: Avoiding memory access vulnerabilities Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-04 04:34 -0600
          Re: Avoiding memory access vulnerabilities Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-04 04:56 -0600
            Re: Avoiding memory access vulnerabilities Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-04 12:07 +0000
              Re: Avoiding memory access vulnerabilities Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-04 09:48 -0600
              Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-04 17:11 +0000
          Re: Avoiding memory access vulnerabilities Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-04 11:55 +0000
    Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 11:33 +0000
      Re: Avoiding memory access vulnerabilities Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-04 20:55 -0500
    Re: Avoiding memory access vulnerabilities Mark Wills <markwills1970@gmail.com> - 2016-03-05 02:55 -0800
      Re: Avoiding memory access vulnerabilities "Elizabeth D. Rather" <erather@forth.com> - 2016-03-10 22:39 -0800
        Re: Avoiding memory access vulnerabilities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-12 12:44 +0000

csiph-web