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

Groups > comp.lang.forth > #45707 > unrolled thread

Avoiding memory access vulnerabilities

Back to article view | Back to comp.lang.forth

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#45725

On 27/02/2016 19:04, Anton Ertl wrote:
> Ron Aaron <rambamist@gmail.com> writes:
>> The user is never* given direct access to memory
> 
> That is actually more or less the idea I explored in my posting,
> except that I allow the programmer to perform classic Forth memory
> accesses in INSECURE code, and there is no effort to prevent the
> programmer from intentionally subverting the SECURE regime.

So in that case, what exactly is meant by 'SECURE'?  Is it simply that
it is intended to be non-writable, but only insofar as the user is not
intent on writing to it?

>> (* except via the FFI,
>> which remains and will probably always remain an Achilles heel).
> 
> Yes, that's one point I thought about mentioning, but didn't.

One other item which doesn't apply I think to ANS: in 8th, strings are
UTF-8, and we enforce validity to prevent certain kinds of attacks based
on invalid UTF-8.  In our case, an invalid string (e.g. caused by the
user converting a buffer into a string) will throw an exception.  That's
somewhat related to the FFI issue as well.

[toc] | [prev] | [next] | [standalone]

#45734

Ron Aaron <rambamist@gmail.com> writes:
>
>
>On 27/02/2016 19:04, Anton Ertl wrote:
>> Ron Aaron <rambamist@gmail.com> writes:
>>> The user is never* given direct access to memory
>> 
>> That is actually more or less the idea I explored in my posting,
>> except that I allow the programmer to perform classic Forth memory
>> accesses in INSECURE code, and there is no effort to prevent the
>> programmer from intentionally subverting the SECURE regime.
>
>So in that case, what exactly is meant by 'SECURE'?

It is an indication from the programmer to the system that this part
of the code does not use memory access words with arbitrary addresses.

What this means is that, if the INSECURE part (plus foreign functions)
of the code does not contain any way to subvert the SECURE regime, the
program is safe from stuff like buffer overflows.  That means that you
only need to inspect the INSECURE part (plus any foreign functions)
carefully for these kinds of problems, not the whole program.

>One other item which doesn't apply I think to ANS: in 8th, strings are
>UTF-8, and we enforce validity to prevent certain kinds of attacks based
>on invalid UTF-8.  In our case, an invalid string (e.g. caused by the
>user converting a buffer into a string) will throw an exception.  That's
>somewhat related to the FFI issue as well.

UTF-8 is also relevant for Forth (in particular Forth-2012), and
validity checking is something that we should have standard support
for, but are still missing; if that is not done, there may be a
vulnerability, but not a memory access vulnerability, so that's
outside the scope of the present discussion.

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

[toc] | [prev] | [next] | [standalone]

#45795

On 2/26/16 3:38 AM, Anton Ertl wrote:
> 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).

I have been following this discussion with interest, but remain somewhat 
mystified. 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, ... )?

Let us assume you, a baddie, want to attack a particular program, a 
production code widely released (else, why bother?). How do you find out 
what implementation it is? Which release? 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. 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, ... )?

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

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#45798

"Elizabeth D. Rather" <erather@forth.com> writes:

<SNIP>

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

Let's not forget:

First rule of attacks on code:

    1. A program can only be attacked if it has defects.

So the first line of defence is to write reliable programs.
Now that is where Forth shines.

>Cheers,
>Elizabeth

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#45804

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>"Elizabeth D. Rather" <erather@forth.com> writes:
>First rule of attacks on code:
>
>    1. A program can only be attacked if it has defects.
>
>So the first line of defence is to write reliable programs.
>Now that is where Forth shines.

Maybe it does, but how do we know it?  Just because there have been no
known attacks does not mean that there are no vulnerabilities.

In this thread, I have pointed out that our current interfaces (e.g.,
the stack effect of MOVE) may lead to mistakes that result in
vulnerabilities, and that we can reduce this effect with better
interfaces.

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

[toc] | [prev] | [next] | [standalone]

#45799

Elizabeth D. Rather <erather@forth.com> wrote:

> Let us assume you, a baddie, want to attack a particular program, a
> production code widely released (else, why bother?). How do you find
> out what implementation it is? Which release? How its data spaces
> and code spaces are arranged?

The computer we're talking about may well be a target-compiled
embedded system, for example a widely-dstributed IP router sold all
over the world.  The bad guys have perfect knowledge of the system,
and can duplicate it.  Of course it's hard to get that information,
but it's not impossible, and the bad guys are very hightly motivated.

> 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 say that the buffer is in the dictionary.  Crafting a packet to
overwite subsequent words in the dictionary with arbitrary code is not
difficult.  Remember that the bad guys have perfect knowledge: you
would be a fool to assume they don't.  Assuming that the bad guys
don't know stuff is called Security Through Obscurity, and it has a
justificably bad reputation.

> Let's assume you know Forth pretty well. 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, ... )?
> 
> 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).

That's all you need to get control over the system, and you're done.
All their packets belong to you.

Andrew.

[toc] | [prev] | [next] | [standalone]

#45801

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:

>Elizabeth D. Rather <erather@forth.com> wrote:

>> Let us assume you, a baddie, want to attack a particular program, a
>> production code widely released (else, why bother?). How do you find
>> out what implementation it is? Which release? How its data spaces
>> and code spaces are arranged?

>The computer we're talking about may well be a target-compiled
>embedded system, for example a widely-dstributed IP router sold all
>over the world.  The bad guys have perfect knowledge of the system,
>and can duplicate it.  Of course it's hard to get that information,
>but it's not impossible, and the bad guys are very hightly motivated.

Let's assume it is a Renesas computer, equipped with ciforth, like
the Elektor board RS32.
If you protect it with a flash password, you cannot do anything
with it except run the turnkey. You cannot even read out the memory
unless you're the NSA, and even then it will be a lot of hassle.

If it is a normal router, it is open source. That may make the task of
a black hacker easier, but it will also make it easier to fix the
defects that made the atack possible in the first place.

>> 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 say that the buffer is in the dictionary.  Crafting a packet to
>overwite subsequent words in the dictionary with arbitrary code is not
>difficult.  Remember that the bad guys have perfect knowledge: you
>would be a fool to assume they don't.  Assuming that the bad guys
>don't know stuff is called Security Through Obscurity, and it has a
>justificably bad reputation.

>> Let's assume you know Forth pretty well. 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, ... )?
>>
>> 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).

>That's all you need to get control over the system, and you're done.
>All their packets belong to you.

So a motivation to make the system in Forth totally.

Let's be realistic. There has never been an attack-with-damage
on a Forth application in the wild.

>Andrew.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#45820

Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> 
>>Elizabeth D. Rather <erather@forth.com> wrote:
> 
>>> Let us assume you, a baddie, want to attack a particular program, a
>>> production code widely released (else, why bother?). How do you find
>>> out what implementation it is? Which release? How its data spaces
>>> and code spaces are arranged?
> 
>>The computer we're talking about may well be a target-compiled
>>embedded system, for example a widely-dstributed IP router sold all
>>over the world.  The bad guys have perfect knowledge of the system,
>>and can duplicate it.  Of course it's hard to get that information,
>>but it's not impossible, and the bad guys are very hightly motivated.
> 
> Let's assume it is a Renesas computer, equipped with ciforth, like
> the Elektor board RS32.

No, let's not.

>>That's all you need to get control over the system, and you're done.
>>All their packets belong to you.
> 
> So a motivation to make the system in Forth totally.
> 
> Let's be realistic. There has never been an attack-with-damage
> on a Forth application in the wild.

Yeah.  And you would know this how, exactly?

Andrew.

[toc] | [prev] | [next] | [standalone]

#45821

Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> 
>>>Elizabeth D. Rather <erather@forth.com> wrote:
>> 
>>>> Let us assume you, a baddie, want to attack a particular program, a
>>>> production code widely released (else, why bother?). How do you find
>>>> out what implementation it is? Which release? How its data spaces
>>>> and code spaces are arranged?
>> 
>>>The computer we're talking about may well be a target-compiled
>>>embedded system, for example a widely-dstributed IP router sold all
>>>over the world.  The bad guys have perfect knowledge of the system,
>>>and can duplicate it.  Of course it's hard to get that information,
>>>but it's not impossible, and the bad guys are very hightly motivated.
>> 
>> Let's assume it is a Renesas computer, equipped with ciforth, like
>> the Elektor board RS32.
> 
> No, let's not.

Sorry, this reply was too rude.  Even putting all the code in flash
doesn't prevent all attacks.  If you can overrun the buffer, then you
can overwrite other data, and this is potentially a security hole.  It
makes no difference if the code in Flash is C or Forth.  Anton's point
is valid.

Andrew.

[toc] | [prev] | [next] | [standalone]

#45824

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:

>Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>> Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>
>>>>Elizabeth D. Rather <erather@forth.com> wrote:
>>>
>>>>> Let us assume you, a baddie, want to attack a particular program, a
>>>>> production code widely released (else, why bother?). How do you find
>>>>> out what implementation it is? Which release? How its data spaces
>>>>> and code spaces are arranged?
>>>
>>>>The computer we're talking about may well be a target-compiled
>>>>embedded system, for example a widely-dstributed IP router sold all
>>>>over the world.  The bad guys have perfect knowledge of the system,
>>>>and can duplicate it.  Of course it's hard to get that information,
>>>>but it's not impossible, and the bad guys are very hightly motivated.
>>>
>>> Let's assume it is a Renesas computer, equipped with ciforth, like
>>> the Elektor board RS32.
>>
>> No, let's not.

>Sorry, this reply was too rude.  Even putting all the code in flash
>doesn't prevent all attacks.  If you can overrun the buffer, then you
>can overwrite other data, and this is potentially a security hole.  It
>makes no difference if the code in Flash is C or Forth.  Anton's point
>is valid.

You didn't read my answer very well. Anton tries to make Forth safer
by tedious software means. A processor like the Renesas provides
a hardware lockdown, where there is no way to access it any way not
provided for by the turnkey. This has little to do with flash. 1]
How would you "hack" a TV-tuner, if the only thing you can do is
pushing one of ten buttons?
And isn't such tuner not a very realistic Forth application, probably
more so than what Anton Ertl has in mind?

1]
You can screw it open, but the bridge to the BDM debug port is burned.

>Andrew.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#45828

Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> 
>>Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> 
>>Sorry, this reply was too rude.  Even putting all the code in flash
>>doesn't prevent all attacks.  If you can overrun the buffer, then you
>>can overwrite other data, and this is potentially a security hole.  It
>>makes no difference if the code in Flash is C or Forth.  Anton's point
>>is valid.
> 
> You didn't read my answer very well. Anton tries to make Forth safer
> by tedious software means. A processor like the Renesas provides
> a hardware lockdown, where there is no way to access it any way not
> provided for by the turnkey. This has little to do with flash. 1]
> How would you "hack" a TV-tuner, if the only thing you can do is
> pushing one of ten buttons?

Well, if you want to restrict Forth to systems which don't connect to
networks, there probably isn't much of an issue.  In which case, the
applications he's thinking about don't affect you; so why would you
care?

> And isn't such tuner not a very realistic Forth application, probably
> more so than what Anton Ertl has in mind?

With the Internet of Things?  I can't see any really strong reason not
to use Forth.

Andrew.

[toc] | [prev] | [next] | [standalone]

#45829

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>You didn't read my answer very well. Anton tries to make Forth safer
>by tedious software means.

The idea is to find a way to make it less tedious to achieve the same
level of security as today (or, alternatively, to be more secure at
the same level of tedium); if I know how to achieve security without
more tedium, I would happily go for it.

>How would you "hack" a TV-tuner, if the only thing you can do is
>pushing one of ten buttons?

I think it has been a long time since TV tuners were sold without
remote control, and remote controls have used a digital protocol for
some decades.  Soon after we got Teletext, another digital protocol.
And for about 2 decades there has been digital video broadcasting
(DVB-S/C/T), and some years ago analog broadcasting has been shut down
in at least Austria and probably other countries as well; so again, a
digital protocol that your tuner has to process.  Finally, in recent
years many TVs sold were SmartTVs that include an Internet connection
and WLAN, and run various apps they can download from an appstore or
something.

Sure, if you time-travel back into the 1970s, you may be able to make
a TV tuner does does not have to deal with digital input other than a
few buttons (and there have even been buffer overflow problems with a
button-press interface, although probably not in an old-style TV
tuner).

>And isn't such tuner not a very realistic Forth application, probably
>more so than what Anton Ertl has in mind?

If you want Forth to be limited to applications that are not connected
to anything else, yes, you don't need to worry about such problems,
but some see Forth as a more general-purpose programming language, and
in that case we should think about how we can provide security.  An
example is net2o, where Bernd Paysan tries to reinvent the Internet.

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

[toc] | [prev] | [next] | [standalone]

#45823

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:

>Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>
>>>Elizabeth D. Rather <erather@forth.com> wrote:
>>
>>>> Let us assume you, a baddie, want to attack a particular program, a
>>>> production code widely released (else, why bother?). How do you find
>>>> out what implementation it is? Which release? How its data spaces
>>>> and code spaces are arranged?
>>
>>>The computer we're talking about may well be a target-compiled
>>>embedded system, for example a widely-dstributed IP router sold all
>>>over the world.  The bad guys have perfect knowledge of the system,
>>>and can duplicate it.  Of course it's hard to get that information,
>>>but it's not impossible, and the bad guys are very hightly motivated.
>>
>> Let's assume it is a Renesas computer, equipped with ciforth, like
>> the Elektor board RS32.

>No, let's not.

>>>That's all you need to get control over the system, and you're done.
>>>All their packets belong to you.
>>
>> So a motivation to make the system in Forth totally.
>>
>> Let's be realistic. There has never been an attack-with-damage
>> on a Forth application in the wild.

>Yeah.  And you would know this how, exactly?

You can't prove a negative. I pose it, you provide an example to
counter it.

>Andrew.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#45802

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

[toc] | [prev] | [next] | [standalone]

#45845

On Thu, 03 Mar 2016 11:33:38 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

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

Security through obscurity can delay a determined hacker long enough
that whomever is being attacked recognizes that they're under attack,
if the system is being actively monitored.  They can then defend
themselves.  It should not be used to provide overall security.

Think of a military sniper, especially those photographs which ask
you to locate the sniper who is hidden in plain sight. The sniper
who is not seen is unlikely to come under attack.  So, the
sniper's camouflage is security through obscurity.  The sniper's
rifle is security through design since he can defend himself when
he comes under attack.

With a complicated enough port knock, who is ever going to find
the access key by chance? ...  Once the port is open, you must
still pass through the security checks, passwords, and encryption.
With sufficient complexity, any problem can become nearly
unsolvable, which is sufficient to reduce threats to a minimum.

Prison security works much the same way, with layers of security.
There are certain prisons where no one has ever escaped.  So,
the opposite, places which have never been entered without
permission, should be true too.

https://en.wikipedia.org/wiki/Port_knocking


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#45852

On Thursday, 3 March 2016 07:19:03 UTC, Elizabeth D. Rather  wrote:
> 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 

If it's a native forth, just replace an address on the return stack
with the address of your baddie code. Sooner or later, it'll run.

[toc] | [prev] | [next] | [standalone]

#45970

On 3/5/16 2:55 AM, Mark Wills wrote:
> On Thursday, 3 March 2016 07:19:03 UTC, Elizabeth D. Rather  wrote:
>> 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
>
> If it's a native forth, just replace an address on the return stack
> with the address of your baddie code. Sooner or later, it'll run.

...assuming it uses the Return Stack that way, and you've been able to 
determine where to find the Return Stack and how to put something on it. 
And if you're successful, how many other programs are actually written 
that way such that your exploit will work?

I take the point that an attacker can potentially analyze the binary 
code of a target program and find an attack, but that will only work for 
this particular target. If what this baddie is trying to do is make a 
virus that will affect many Forths, it will be much harder.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#45984

"Elizabeth D. Rather" <erather@forth.com> writes:
>I take the point that an attacker can potentially analyze the binary 
>code of a target program and find an attack, but that will only work for 
>this particular target. If what this baddie is trying to do is make a 
>virus that will affect many Forths, it will be much harder.

Sure it will be much harder.  But even if an exploit that works on all
Forth systems would be impossible, the problem of possible attacks
against a specific program running on a specific system still exists,
and we should be thinking about supporting the programmers in
defending agains that, at least if we don't want to limit Forth to
application areas like 1960s TVs as suggested by Albert van der Horst.

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web