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
>
>
