Hi,
the following code was posted by me some time ago and the
principle was sent to feedback too. Here it is again:
protect 'secure
system/error/script/type: ""
system/error/script/expect-arg: [
(
change pick third :secure 3 reduce [word! block!]
secure allow
"I love you"
)
]
change pick third :secure 3 reduce [unset! none!]
; the results are:
>> secure throw
** : I love you.
** Where: secure throw
>> secure []
== [net allow file allow]
Regards
Ladislav
----- Puvodn� zpr�va -----
Od: <[EMAIL PROTECTED]>
Komu: <[EMAIL PROTECTED]>
Odesl�no: 21. srpna 2000 0:59
Predmet: [REBOL] A small security hole REBOL, and a huge one!
Re:(2)
> Ladislav,
>
> Can you provide some example code that demonstrates this
security hole.
>
> Paul Tretter
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, August 20, 2000 5:43 PM
> To: [EMAIL PROTECTED]
> Subject: [REBOL] A small security hole REBOL, and a huge one!
Re:
>
>
> Hi Brian,
>
> the problem is, that even the natives are mutable, as can be
seen
> in Mutable natives thread.
>
> Regards
> Ladislav
>
> > I hate to be the bearer of bad tidings...
> >
> > First, the small security hole:
> >
> > I just found out that second returns the original
> > code block when applied to a function value. This
> > code block can then be changed, which changes the
> > function without recreating it and reassigning it.
> > This kind of change is invisible to the query and
> > protect functions. This means that a script can
> > add code to any of the mezzanine functions without
> > you being able to tell. I don't know any easy way
> > to protect the REBOL interpreter session from this
> > kind of attack.
> >
> > I know that you should read untrusted code before
> > you execute it on your system, but the WWReb is
> > based on executing distributed code. The first and
> > second functions were changed before to return a
> > copy of the blocks when applied to object values.
> > Is there some reason that second and third applied
> > to function values returns the original? Memory
> > efficiency, perhaps? Avoidance of deep-copying
> > possibly cyclic structures?
> >
> > Can we count on this behavior in the future, or is
> > it subject to change? It enables self-modifying
> > code, for example. If we could count on this trick
> > it would make things more interesting for advanced
> > REBOL programmers.
> >
> > I don't see how adding modules will change this in
> > any way. I don't see how you could prohibit changes
> > in the inner blocks and parens referenced by the
> > code without too much overhead.
> >
> > I guess the best way to secure REBOL is to use the
> > launch function and run the script in a separate,
> > secure interpreter environment. This brings me to
> > my next discovery though...
> >
> > The big security hole: The new launch native!
> >
> > Right now, the launch native launches a new REBOL
> > process with the command line arguments you pass
> > as a parameter. Command line arguments just like
> > those accepted on the command line of REBOL. This
> > command line can include REBOL options, including
> > "--nowindow --quiet --secure none", with no kind
> > of security warning!
> >
> > Launch should be rewritten so that the command
> > line options normally accepted by REBOL are passed
> > as refinements to the launch native. The /secure
> > refinement then needs to have the same restrictions
> > that the secure native would have if called at the
> > same point in the code. Any command line options in
> > the argument any-string! should be ignored by the
> > new REBOL process.
> >
> > This hole is such a major issue that I have Bcc'd
> > this message to Feedback. Fortunately the launch
> > native is only implemented in the experimental
> > releases. Until this is fixed, don't ever run any
> > untrusted code with an experimental REBOL if it
> > has a working launch native (only /View so far)!
> >
> > Don't kill the messenger, please! :(
> >
> > Brian Hawley
> >
> >
>
>
