Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #45776

Re: Avoiding memory access vulnerabilities

Show all headers | View raw

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Am Sat, 27 Feb 2016 15:31:05 +0000 schrieb Anton Ertl:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Am Sat, 27 Feb 2016 07:15:05 +0000 schrieb Anton Ertl:
>>>Having a dictionary layout similar to a Flash system (write-once code in
>>>one segment, write-many buffers and variables in another segment) could
>>>prevent accidential overwriting of code.
>> 
>> I am not sure that accidental overwriting of data is better (even if it
>> is not code addresses).
>
>Depends on the data.  You want to overwrite deferred words or similar to 
>get remote execution.

What I meant is that, for *accidental* overwrites, overwriting code
may be preferable because it probably causes a crash, while
accidentally overwriting data is more likely to go undetected and
maybe deliver wrong results.

For attacks, any arbitrarily deep indirect reference to code that is
used later for executing the code is an attack vector.  Also, if you
can overwrite the address of a memory location that will be stored to
later, and also overwrite the data that will be stored there, you now
have an arbitrary write in writable memory, so that opens up all
memory to your attack (including separate return stack or other
separation attempts).

>Things an attacker want to overwrite:
>
>* code
>* pointers to code
>* vtable pointers (pointers to pointers to code)
>* data that is evaluated by jump tables (index to pointers to code)

* pointers to pointers to pointers to code (e.g., an object address)
* pointers to pointers to pointers to pointers to code
* ...
* Addresses for data writes where the attacker can also determine the data

>For buffer writes, we usually have words that take addr len instead of 
>just addr as in libc (with a bunch of recent replacement words which do 
>take a length).

Well, MOVE takes one length.  Do you use the buffer length, or the
source length.  Probably the latter, hopefully after checking that it
fits into the buffer.  It sure is better than strcpy(), but it's far
from perfect.

>  The problem is that the buffers itself don't keep the 
>length, especially with BUFFER: we screwed up: It should really return an 
>addr len pair, so that e.g.
>
>256 buffer: line
>
>...
>line fd read-line throw
>
>would be straight-forward.  Instead, you have to write
>
>line 256 fd read-line throw
>
>and then maybe you run into RAM pressure, decide that 128 bytes is enough 
>for a line, but forget to adjust the code that uses read-line.

So always passing the buffer length on the stack, and supplying words
that always push the buffer length, and also providing words that
consume the buffer-length (say, BMOVE ( afrom ufrom ato uto -- ior ))
would be one option, but would increase the stack clutter.

Some alternatives I have thought about:

1) Buffers always come with their length in the cell right before the
start.  Then we would have BMOVE ( afrom ufrom buffer -- ior ), and
BMOVE would always fetch the length and check it.  Likewise, we would
get BREAD-LINE ( buffer fid -- u ior ).  Disadvantage: We cannot, say,
BMOVE into the middle of a buffer, so we would have to fall back to
the MOVE for that, or alternatively have a word where we supply a
buffer and an offset from the start of the buffer as target.

2) To work around the middle-of-the-buffer problem, we could have
buffer descriptors in memory consisting of start address and length of
the buffer we want to write into, and words for getting descriptors of
buffer parts out of existing buffers.  Disadvantage: The additional
descriptors have to be memory-managed, which is cumbersome.

- 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 — Previous in thread | 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