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. > (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? That is fraught with dangers. 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). 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. > 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. 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). - anton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
