Avoiding memory access vulnerabilities

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups	comp.lang.forth
Subject	Avoiding memory access vulnerabilities
Date	2016-02-26 13:38 +0000
Organization	Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID	<2016Feb26.143842@mips.complang.tuwien.ac.at> (permalink)

Show all headers | View raw

A frequent source of vulnerabilities in C is buffer overflows: A
memory access can happen outside the bounds of an array or otherwise
outside the bounds of an object (C terminology, in Forth standard
terminology the relevant term is "contiguous region"); the classic
case is to have a store that overwrites the return address adjacent to
the buffer and leads to arbitrary code execution (in Forth return
addresses are typically not close to buffers, but just consider a
variable or field containing an xt close to the buffer, so Forth is
not immune to that).  Or the buffer overflow could be a memory fetch
of data that is then sent to the attacker (the heartbleed
vulnerability was of this type, helped along by overzealous
"optimization").

The typical idea of C and Forth programmers with respect to this kind
of danger is to take more care when programming, so that the
vulnerability is avoided.  But that has not worked for C programs, and
I guess it does not work for Forth programs, either, at least for big
ones.  Programmers also want to avoid bugs by taking care, but somehow
bugs tend to creep into programs.  In the Forth community we tend to
find bugs by testing, but vulnerabilities often don't show up in
regular testing, and I don't think there is a testing regime that is
guaranteed to find all memory-access vulnerabilities.

So what else can we do?  The idea I am going to explore here is to
limit the part where you have to take special care to a small part of
the program; that goes nicely with the idea that you write an
application-specific wordset and use that to program the application.

The idea is to make the memory access words that take arbitrary
addresses (@ ! c@ c! etc.) only visible in the small special-care
parts, and use more restricted replacements for these words in the
rest of the program.  E.g., one could make them visible with INSECURE
and make them invisible with SECURE.  The programmers are responsible
themselves for not making these words available through aliases,
deferred words, etc., and of course for not putting vulnerabilities in
the INSECURE code.

How would the replacements look?

Arrays: here one would have words that take an array descriptor and
index, and perform an index check before performing the fetch or
store.  Maybe TH@ TH!, or, based on the FSL, }@ }! (just examples, one
would need a full complement for various types and number of array
dimensions; hmm, this appears to become a large number of words; what
can one do about that?).  For iterating over arrays, one would have
macros that iterate from one index to another, delivering one element
per iteration, to make it possible to do the bounds check once instead
of once per iteration.  Maybe some more common cases of iterating over
arrays can be optimized with special words or macros.

Simple variables: Actually here the checking is not so important in
principle, because one does not buffer-overflow on V @ or V !.
However, because @ and ! are not visible, and we don't want people to
misuse their replacements, the replacements should be able to do
run-time checks in principle, with the option to disable the checks
after testing; (in contrast to arrays, one can test variable accesses
exhaustively).  My idea is to have words @v !v c@v c!v etc., that can
access only variables (checked at run-time by comparing a signature
field beside the data field).  The signature is filled with a random
value.  Alternatively, one could use a dot-parser recognizer that
accepts V.@ V.! if V is a variable.

Structure fields: Like for variables, the checking is not as essential
as for arrays here, but we have to replace @ ! etc.  Let's assume a
structure S with a field F.  Typical source code patterns are to have
F @, F !, @ F, or ! (where the stored value points to an S).  One
could have a dot-parser that recognizes F.@ F.! @.F and S.! for these
patterns.  One could have an option to add a signature field to a
structure, and let the generated code check the signature of the
involved structure.  This could actually be quite useful in debugging,
not just for security.

MOVE FILL etc.: One might consider these words secure, because you
pass it the buffer size anyway.  However, at least for MOVE the passed
size is derived from the source buffer size and may exceed the target
buffer size; or one uses some address arithmetic for determining the
address and size for FILL, which may also incur errors.  So one could
have replacements for these words that take a buffer descriptor and
offset/address for the target, and checks that all accesses performed
lie within the target.  I am not sure about this, but the C11 standard
has added variants of many library functions with the target buffer
size as additional parameter (e.g., memmove_s() as
memmove()-replacement).

What is there to do?  Refine this sketch some more, do a prototype
implementation, and try how well this idea works when one is
programming, and how much the overhead of checking is (for the
required array checks, and for the optional variable and field
checks).

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

Back to comp.lang.forth | Previous | Next — Next in thread | Find similar | Unroll thread

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