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

Groups > comp.lang.forth > #45802

Re: Avoiding memory access vulnerabilities

Show all headers | View raw

"Elizabeth D. Rather" <erather@forth.com> writes:
>I don't know much about C, but a fair amt about Forth. Among 
>the things I know about Forth is that implementations vary dramatically: 
>from the obvious distinction between ITC, DTC, STC, and compile-to=code, 
>to dictionary organization (e.g. data space separated from code space or 
>intermingled; header arrangement, ... ).
>
>With all these variances, what kinds of vulnerabilities does "Forth" 
>(per se) have? Let's assume for the moment that I want to write an 
>attack on a Forth program, using a buffer overflow error. I have a bit 
>of code (machine language) that does the bad thing I want to do, and I 
>want to con some Forth program into branching to it. How would I do 
>that? How does managing to store outside a defined buffer area achieve 
>any of my malevolent intentions? Given the incredible variety of Forth 
>implementations, how can any of my assumptions work for more than one 
>particular known implementation (swiftForth, eForth, figForth, VFX, 
>gForth, jonesForth, one-off experiments, ... )?

It's sufficient if your assumptions work for the actual Forth system
the attacked system uses.

>Let us assume you, a baddie, want to attack a particular program, a 
>production code widely released (else, why bother?).

If it's widely released, it's certainly of interest to attackers who
want to attack many people (like the file-encryption blackmailers that
are rampant now).  OTOH, if the attacker wants to attack one specific
person, any program that person uses is of interest.  On the gripping
hand, it may be cheaper to attack that person using social engineering
than by finding vulnerabilities in the software.

>How do you find out 
>what implementation it is? Which release?

If you don't care who you hit, you just go for one or more widely-used
implementations or releases.  If you want to attack someone specific,
there are ways to find out.  Much software announces itself (e.g,
OpenSSH tells the implementation release when you contact it), but
even if it does not, you can often know such things from the way the
software behaves; e.g., different OSs have behavioural differences
(all within the scope of the standard) in their TCP/IP implementation.
A Forth example would be to look at the output of .S, ORDER or SEE.
You can determine the Forth system from that.  And there are other
ways to find out, including social engineering, watching your internet
traffic (e.g., what updates do you pull, or what help files do you
access), etc.

As Andrew Haley writes, security by obscurity has a deservedly bad
name, because it does not help against a determined attacker.

> How its data spaces and code 
>spaces are arranged? Assuming you can write some code that declares a 
>buffer and then tries to store beyond its memory. How do you
>deliver the address to the Forth system to cause it to be executed? 
>Let's assume you know Forth pretty well.

It's actually not necessary that the attackers know Forth well.  They
look at what the machine code does, and analyse that.  There are
pretty good tools for ordinary programmers that work that way these
days, and I guess the black hats have such tools tuned to their needs.

> Do you want to push the address 
>of your evil code on the Return Stack? If so, do you know how RStack 
>addresses are accessed? How do you do this push, anyway, since you don't 
>know where the Return Stack pointer is (in a register, and if so, which, 
>and assuming what kind of jump? In memory? Where?) What is its format 
>(machine code, dtc addresses, stc addresses, mixture, ... )?

As I wrote, the more likely approach in Forth is to overwrite an xt
that is then EXECUTEd (as for whether it is a native-code, DTC or ITC
or whatever system, the attack is of course specific to the system),
or, if accessible, overwrite e.g., code addresses in word headers.

>There's a lot of folklore about attacks that assume C code, because it's 
>ubiquitous, but I'm not at all sure these attacks would get far against 
>more than one Forth program (and that assumes knowledge of which Forth 
>that program is and how its Forth worked at that point in time).

If a Forth program has a buffer overflow vulnerability, there is a
pretty good chance that it can be exploited for arbitrary code
execution, using the mechanisms discussed above and in earlier
postings.

- 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