Joel Rees wrote: > 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.
There are only two places in Gforth that call QUIT. In batch/script mode (i.e., as long as Gforth is processing the OS command line; this is what a CGI script would use) Gforth does not call QUIT. If you want to make sure that the text interpreter will not be invoked, you can say something like ' bye is 'quit > > 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? No. > 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?) Native code is elsewhere, but that does not help you, as writing an arbitrarily indirect pointer to code (e.g., threaded code and the CFA) opens the door to the attacker. And you cannot separate the CFAs from the headers. What you should do is to put the application data elsewhere (e.g., in an ALLOCATEd region). However, the primary defense should be not to create buffer overflows. - anton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
