Dang. It sounds like you guys have already done all the fun stuff. :-) Thanks for the leads. I'm going to have to give this a try.
Joel On Mon, 17 Mar 2003 10:27:16, Bernd Payson elucidated: > On Monday 17 March 2003 09:52, Joel Rees wrote: > > 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. > > QUIT and ABORT in Gforth work through THROW, which can be isolated by CATCH, > so that you never go to the outer interpreter. Also, start Gforth with > --die-on-signal, so that it exits when illegal accesses are performed. > Restricting assembler words does not help anything, since > plattform-dependent code can be pre-assembled and compiled with , and C, > anyway. > > > In order to restrict access to dangerous words, I'm thinking the symbol > > table may need to provide ways to build walls between vocabularies. (I > > had a start on that a long time ago, using a forest of nested binary > > trees for my dictionary, but I haven't looked very closely at the > > dictionary structure in gforth. Hash table?) > > Gforth's vocabularies and its vocabulary stack provides sufficient means to > create an isolated symbol table for application purposes. See for example > httpd.fs, which has commands and values for HTTP headers in their own > vocabulary, and switches between those with > > commands 1 set-order > > and > > values 1 set-order > > Buffer overflows are avoided there by using a special string library > (string.fs) that expands strings in the heap as necessary, and otherwise by > relying on Gforth's internals (like REFILL) to be buffer-overflow-proof. > REFILL also expands the TIB as necessary. > > > 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? > > There's a separate local stack. You usually don't set up a buffer on the > return stack, buffer space is either heap or (not as typical) local stack. -- Joel Rees <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
