Anton Ertl replied: > Joel Rees wrote: > > > > Wondering, and I hope no one thinks me rude in doing so out loud, if > > there might not be inherent security issues in using forth to field cgi. > > There are always security issues with CGI.
True. > > (Been interested in this sort of thing for quite a while, but not had > > time to pursue it.) > > > > I'm thinking that it would be necessary to write a restricted outer > > interpreter that would, at minimum, (1) restrict access to the assembler > > and to most file or networking words, and (2) absolutely never execute > > the standard QUIT or ABORT words, or any words like them, or any words > > that invoked them. > > Why? Do you want to interpret stuff coming from the net? No. But I don't want to worry about my server hitting something like a QUIT buried deep in some server-side code and putting INTERPRET belly-up to the browser. Of course, if I know what words to look for, it's not (too?) hard to ferret them out and replace them. > That is fraught with dangers. Yes, it is. I'm thinking of things like settings files (cookie-like beasts) that would exist on the client side. A restricted interpreter is definitely in order, but it would also be nice to be able to sand-box the vocabulary it works from. (Yeah, I'm kind of thinking of re-inventing Java, but doing it right this time.) > If you want to do that, you will have to restrict most words (e.g., > eliminate all words that take an addresses and write there; such words > could be used to reprogram Gforth to do anything). Ergo, a restricted form of store and allot, but preferably no allot at all. (And a few other such words.) > If you don't want to pass data coming from the net to the text > interpreter, the things you propose are not necessary; you just have > to make sure that there are no programming errors such as buffer > overflows that would allow an attacker to write stuff into Gforth's > memory where it should not. Has this sort of code audit ever been performed on gforth? > > It does seem like having return addresses on a separate stack would help > > a lot with buffer overflow issues, although it would not be a perfect > > wall against exploits. Auditing for buffer overflows and similar issues > > would be required? > > Certainly. A typical Gforth buffer overflow would not go through the > stack, but through the dictionary: A word follows your buffer in the > dictionary, the attacker overwrites that word's code field, and when > the word is executed the attacker's code gains control. That's right. gforth has the code, data, and symbol table all in the same segment. Is it considered to be a lot of work to at least separate code out? (I think, for instance, it alters the semantics of the allot primitive?) > However, Forth is generally less vulnerable to buffer overflows than > C, because it has a better string representation (see comp.lang.forth > discussions on buffer overflows). Good idea. -- Joel Rees <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
