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

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

CGI scripting (in 8th)

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

Contents

  CGI scripting (in 8th) Ron Aaron <rambamist@gmail.com> - 2015-10-13 16:56 +0300
    Re: CGI scripting (in 8th) foxaudioresearch@gmail.com - 2015-10-13 10:51 -0700
      Re: CGI scripting (in 8th) "Elizabeth D. Rather" <erather@forth.com> - 2015-10-13 08:05 -1000
        Re: CGI scripting (in 8th) foxaudioresearch@gmail.com - 2015-10-13 11:54 -0700
      Re: CGI scripting (in 8th) Ron Aaron <rambamist@gmail.com> - 2015-10-13 21:22 +0300
        Re: CGI scripting (in 8th) foxaudioresearch@gmail.com - 2015-10-13 11:53 -0700
          Re: CGI scripting (in 8th) "Elizabeth D. Rather" <erather@forth.com> - 2015-10-13 11:57 -1000
          Re: CGI scripting (in 8th) Ron Aaron <rambamist@gmail.com> - 2015-10-14 08:04 +0300
            Re: CGI scripting (in 8th) Paul Rubin <no.email@nospam.invalid> - 2015-10-13 23:18 -0700
              Re: CGI scripting (in 8th) Ron Aaron <rambamist@gmail.com> - 2015-10-14 09:25 +0300
              Re: CGI scripting (in 8th) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-14 09:33 +0000
      Re: CGI scripting (in 8th) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-14 09:50 +0000
        Re: CGI scripting (in 8th) foxaudioresearch@gmail.com - 2015-10-15 11:31 -0700

#42616 — CGI scripting (in 8th)

It's not just for mobile and desktop:

http://8th-dev.com/forum/index.php/topic,595.msg3177.html

[toc] | [next] | [standalone]

#42617

On Tuesday, October 13, 2015 at 9:56:47 AM UTC-4, Ron Aaron wrote:
> It's not just for mobile and desktop:
> 
> http://8th-dev.com/forum/index.php/topic,595.msg3177.html

One of the common complaints I have heard when it was suggested to Forth for CGI was that it was a security risk.  Does 8th include ways to preempt that concern out of the box?  Perhaps you can "seal" it to a specific wordlist or some such thing.

B

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

#42618

On 10/13/15 7:51 AM, foxaudioresearch@gmail.com wrote:
> On Tuesday, October 13, 2015 at 9:56:47 AM UTC-4, Ron Aaron wrote:
>> It's not just for mobile and desktop:
>>
>> http://8th-dev.com/forum/index.php/topic,595.msg3177.html
>
> One of the common complaints I have heard when it was suggested to Forth for CGI was that it was a security risk.  Does 8th include ways to preempt that concern out of the box?  Perhaps you can "seal" it to a specific wordlist or some such thing.

Sealed vocabularies have been used to provide security since the 70's. 
You can limit the available words to a few application-specific commands 
or even provide secure redefinitions of normal Forth words with 
protections such as checking limits of addresses or offsets. Forth 
applications can be made extremely secure.

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]

#42622

On Tuesday, October 13, 2015 at 2:05:06 PM UTC-4, Elizabeth D. Rather wrote:
> On 10/13/15 7:51 AM, foxaudioresearch@gmail.com wrote:
> > On Tuesday, October 13, 2015 at 9:56:47 AM UTC-4, Ron Aaron wrote:
> >> It's not just for mobile and desktop:
> >>
> >> http://8th-dev.com/forum/index.php/topic,595.msg3177.html
> >
> > One of the common complaints I have heard when it was suggested to Forth for CGI was that it was a security risk.  Does 8th include ways to preempt that concern out of the box?  Perhaps you can "seal" it to a specific wordlist or some such thing.
> 
> Sealed vocabularies have been used to provide security since the 70's. 
> You can limit the available words to a few application-specific commands 
> or even provide secure redefinitions of normal Forth words with 
> protections such as checking limits of addresses or offsets. Forth 
> applications can be made extremely secure.
> 
> 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."
> ==================================================

Yes I knew about this from conventional Forth systems. Don't know much about 8th.  New more life span I think.

B

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

#42619

On 10/13/15 20:51, foxaudioresearch@gmail.com wrote:
> On Tuesday, October 13, 2015 at 9:56:47 AM UTC-4, Ron Aaron wrote:
>> It's not just for mobile and desktop:
>>
>> http://8th-dev.com/forum/index.php/topic,595.msg3177.html
>
> One of the common complaints I have heard when it was suggested to Forth for CGI was that it was a security risk.  Does 8th include ways to preempt that concern out of the box?  Perhaps you can "seal" it to a specific wordlist or some such thing.

Yes indeed, you can create a sealed vocabulary.

I don't see why Forth would be any more of a security risk for CGI than 
any other language, honestly.

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

#42621

On Tuesday, October 13, 2015 at 2:22:43 PM UTC-4, Ron Aaron wrote:
> On 10/13/15 20:51, foxaudioresearch@gmail.com wrote:
> > On Tuesday, October 13, 2015 at 9:56:47 AM UTC-4, Ron Aaron wrote:
> >> It's not just for mobile and desktop:
> >>
> >> http://8th-dev.com/forum/index.php/topic,595.msg3177.html
> >
> > One of the common complaints I have heard when it was suggested to Forth for CGI was that it was a security risk.  Does 8th include ways to preempt that concern out of the box?  Perhaps you can "seal" it to a specific wordlist or some such thing.
> 
> Yes indeed, you can create a sealed vocabulary.
> 
> I don't see why Forth would be any more of a security risk for CGI than 
> any other language, honestly.

Its the perception that the entire machine is accessible from within Forth. I have heard coming from system admin types who are scared to death of programs the can do things they don't really understand.

Thanks for the fast reply.

B

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

#42627

On 10/13/15 8:53 AM, foxaudioresearch@gmail.com wrote:
> On Tuesday, October 13, 2015 at 2:22:43 PM UTC-4, Ron Aaron wrote:
>> On 10/13/15 20:51, foxaudioresearch@gmail.com wrote:
>>> On Tuesday, October 13, 2015 at 9:56:47 AM UTC-4, Ron Aaron wrote:
>>>> It's not just for mobile and desktop:
>>>>
>>>> http://8th-dev.com/forum/index.php/topic,595.msg3177.html
>>>
>>> One of the common complaints I have heard when it was suggested to Forth for CGI was that it was a security risk.  Does 8th include ways to preempt that concern out of the box?  Perhaps you can "seal" it to a specific wordlist or some such thing.
>>
>> Yes indeed, you can create a sealed vocabulary.
>>
>> I don't see why Forth would be any more of a security risk for CGI than
>> any other language, honestly.
>
> Its the perception that the entire machine is accessible from within Forth. I have heard coming from system admin types who are scared to death of programs the can do things they don't really understand.
>
> Thanks for the fast reply.

In embedded and native Forths, indeed the entire machine is accessible 
to the application developer. That is a good thing. However, the 
completed application can be as secure as it needs to be.

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]

#42631

On 10/13/2015 21:53, foxaudioresearch@gmail.com wrote:
> Its the perception that the entire machine is accessible from within Forth. I have heard coming from system admin types who are scared to death of programs the can do things they don't really understand.

Ah.  Well, 8th doesn't have any more machine access than any C 
program... so the same caveat would apply to a CGI program written in C.

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

#42632

Ron Aaron <rambamist@gmail.com> writes:
> On 10/13/2015 21:53, foxaudioresearch@gmail.com wrote:
>> Its the perception that the entire machine is accessible from within Forth.
> Ah.  Well, 8th doesn't have any more machine access than any C
> program... so the same caveat would apply to a CGI program written in C.

The concern with C is that it's possible for malicious client programs
to inject arbitrary code into a running C cgi that's buggy, such as by
overwriting return addresses on the stack to point into data buffers
that the client sent.  "Safe" languages like Python and (cough) Java
prevent these attacks by a mixture of more compile time type safety and
more runtime checks against out-of-range subscripts and the like.  As
Elizabeth explained, it's possible to do that in Forth by redefining
Forth's low-level memory access words to check for safety, etc.  But I
thought 8th was more like a scripting interpreter that checked
everything by default.  That would make it safer than C.

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

#42633

On 10/14/2015 09:18, Paul Rubin wrote:
> Ron Aaron <rambamist@gmail.com> writes:

> that the client sent.  "Safe" languages like Python and (cough) Java
> prevent these attacks by a mixture of more compile time type safety and
> more runtime checks against out-of-range subscripts and the like.  As
> Elizabeth explained, it's possible to do that in Forth by redefining
> Forth's low-level memory access words to check for safety, etc.  But I
> thought 8th was more like a scripting interpreter that checked
> everything by default.  That would make it safer than C.
>

Yes, it's safer than C; there's no direct memory access, and buffers and 
strings are length-checked.  So even in plain script-mode, it's much 
safer than C.

Additionally, were one to use an encrypted 8th app for CGI, it would be 
impossible to modify it without "breaking it" fatally (e.g. it will not 
run at all).

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

#42637

Paul Rubin <no.email@nospam.invalid> writes:
>The concern with C is that it's possible for malicious client programs
>to inject arbitrary code into a running C cgi that's buggy, such as by
>overwriting return addresses on the stack to point into data buffers
>that the client sent.  "Safe" languages like Python and (cough) Java
>prevent these attacks by a mixture of more compile time type safety and
>more runtime checks against out-of-range subscripts and the like.

Nice theory.  In practice, such languages and their run-time systems
(and the libraries written in C) also have their bugs, and last year I
listened to a master's thesis where the topic was how to increase the
safety against attacks in such a "safe" language (IIRC it was
JavaScript).  The premise of the work (which the student did not even
mention) was that the attacker can write to pretty much any writable
memory; so apparently that work had given up on the idea that the
"safe" language prevents such vulnerabilities; the current perception
of Java as insecure does not support your theory, either.

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

#42639

foxaudioresearch@gmail.com writes:
>On Tuesday, October 13, 2015 at 9:56:47 AM UTC-4, Ron Aaron wrote:
>> It's not just for mobile and desktop:
>> 
>> http://8th-dev.com/forum/index.php/topic,595.msg3177.html
>
>One of the common complaints I have heard when it was suggested to Forth for CGI was that it was a security risk.  Does 8th include ways to preempt that concern out of the box?  Perhaps you can "seal" it to a specific wordlist or some such thing.

You can also seal in Forth, but that's normally not an issue in CGI
programs, because there you don't normally text-interpret the data
coming from the user (of course, if you do text-interpret it, e.g.,
with EVALUATE, you want to seal the search order).

In a bug-free CGI program, whether written in Forth, C, Perl, Python,
or whatever, and assuming that the language implementation is
bug-free, too, there are no vulnerabilities that allow an attacker to
make the process do things that the program was not designed to do.

Unfortunately, programs often have bugs.  That has led to the theory
that, if you use a language that allows only restricted ways of
writing to memory ("safe languages"), you cannot have bugs that allow
arbitrary code execution.  Unfortunately, there are still bugs like
SQL injection attacks possible in such languages, as well as bugs in
the language implementation that allow arbitrary code execution
attacks even on programs written in "safe languages".

It all comes down to whether you think that your Forth (or 8th)
program combined with your Forth (or 8th) implementation will be more
secure than the alternative.

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

#42645

On Wednesday, October 14, 2015 at 6:00:07 AM UTC-4, Anton Ertl wrote:
> foxaudioresearch@gmail.com writes:
> >On Tuesday, October 13, 2015 at 9:56:47 AM UTC-4, Ron Aaron wrote:
> >> It's not just for mobile and desktop:
> >> 
> >> http://8th-dev.com/forum/index.php/topic,595.msg3177.html
> >
> >One of the common complaints I have heard when it was suggested to Forth for CGI was that it was a security risk.  Does 8th include ways to preempt that concern out of the box?  Perhaps you can "seal" it to a specific wordlist or some such thing.
> 
> You can also seal in Forth, but that's normally not an issue in CGI
> programs, because there you don't normally text-interpret the data
> coming from the user (of course, if you do text-interpret it, e.g.,
> with EVALUATE, you want to seal the search order).
> 
> In a bug-free CGI program, whether written in Forth, C, Perl, Python,
> or whatever, and assuming that the language implementation is
> bug-free, too, there are no vulnerabilities that allow an attacker to
> make the process do things that the program was not designed to do.
> 
> Unfortunately, programs often have bugs.  That has led to the theory
> that, if you use a language that allows only restricted ways of
> writing to memory ("safe languages"), you cannot have bugs that allow
> arbitrary code execution.  Unfortunately, there are still bugs like
> SQL injection attacks possible in such languages, as well as bugs in
> the language implementation that allow arbitrary code execution
> attacks even on programs written in "safe languages".
> 
> It all comes down to whether you think that your Forth (or 8th)
> program combined with your Forth (or 8th) implementation will be more
> secure than the alternative.
> 
> - 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/

I had always wondered about that "safe" hype from the Java crowd when it first came out.  My original question implied using a Forth like language created on top of a Forth interpreter to run the CGI.  So sealing the vocabulary would be
the first part of security.  Of course re-writing memory access words would be
simple in Forth as well.

But it appears to your point Anton, that CGI security is far more
implementation dependent than language dependent and we don't know about the
bugs until the bad guys have thoroughly "reviewed" our implementation looking
for holes.

It's related to a conference I attended as a guest panelist when I was with a
Financial Services company.  This Canadian Mobile phone company (wink wink) had
brought together hundreds experts on elliptical encryption.  I sat through the first day's lectures and followed some of it since it was not too detailed.


When the panel convened with people from the banks and credit card companies
etc. , were asked to comment on security in our respective industries.  My
comment was that the rigor with which the technology was secured based on what
I had seen that day, seemed amazing, but in my world people hacked the
"wetware" as well.

Example:  
Victim: Hello, who is it?
Criminal: It's your favourite grandson!
Victim:  David?
Criminal:  Yes. Don't tell my parents but I need some money ... 
           can you go to Western Union?

Secure technology can't protect you completely. :-)

BF

[toc] | [prev] | [standalone]

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

csiph-web