A small security hole REBOL, and a huge one!
[1/7] from: brian:hawley:bigfoot at: 18-Aug-2000 23:46
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
[2/7] from: lmecir:geocities at: 21-Aug-2000 0:43
Hi Brian,
the problem is, that even the natives are mutable, as can be seen
in Mutable natives thread.
Regards
Ladislav
[3/7] from: ptretter:charter at: 20-Aug-2000 17:59
Ladislav,
Can you provide some example code that demonstrates this security hole.
Paul Tretter
[4/7] from: lmecir:geocities at: 21-Aug-2000 16:17
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: <[ptretter--charter--net]>
Komu: <[list--rebol--com]>
Odesláno: 21. srpna 2000 0:59
Predmet: [REBOL] A small security hole REBOL, and a huge one!
Re:(2)
[5/7] from: jeff:rebol at: 21-Aug-2000 7:45
Launch, at least in its present form, will not likely be in
the regular distribution. It went out in the windows view
version by accident.
The security risks of modifiable REBOL code will be best
dealt with by modules. Untrusted REBOL code can evaluate in
a module prevented from affecting the surrounding execution
environment.
Besides, only good hackers use REBOL! ;-) Why would
someone be so evil as to make good little REBOL do something
bad?! (-;
Just goofin' --
head reverse mold disarm catch reduce [
func [[throw]][throw-on-error [no flames]]
]
-jeff
[6/7] from: brian:hawley:bigfoot at: 21-Aug-2000 12:32
Jeff ([jeff--rebol--net]) wrote:
>Launch, at least in its present form, will not likely be in
>the regular distribution. It went out in the windows view
>version by accident.
Good to hear. What do you think about my suggestion for the
changes to the function interface? I think it would help...
I sent that message to Feedback as well but I got no reply.
Did it go through?
>The security risks of modifiable REBOL code will be best
>dealt with by modules. Untrusted REBOL code can evaluate in
>a module prevented from affecting the surrounding execution
>environment.
I'd be curious to see how that is done. The current module
spec doesn't prohibit the kind of change to the code of the
mezzanine functions that I outlined, nor the hacks involving
changes to the specs that Ladislav mentioned.
The problem with the current module spec is that once you
make a function visible inside a module so that it can be
used there, that function can be modified. The problem is
not with the security of modules, but that of functions.
I suppose that it would be too expensive to copy/deep the
code blocks and specs when second and third are applied to
functions. Perhaps a way of marking those values as read-
only once they have been used in a function, maybe with a
copy-on-write strategy? That would at least protect the
inner workings of functions. Protect the specs too so that
Ladislav's hack won't work either.
Don't misunderstand, I'm as much a fan of self-modifying
code as the next mad scientist - it's just that I'm willing
to give up modifiable functions for security reasons. We
should be able to get by with replaceable functions, since
we can easily track assignment if we want to. If we still
need self-modifying code we can still do blocks.
>Besides, only good hackers use REBOL! ;-) Why would
>someone be so evil as to make good little REBOL do
>something bad?! (-;
A jealous Perl enthusiast, perhaps? :-)
Brian Hawley
[7/7] from: jeff:rebol at: 21-Aug-2000 13:30
Howdy, Brian:
> >The security risks of modifiable REBOL code will be best
> >dealt with by modules. Untrusted REBOL code can evaluate
<<quoted lines omitted: 4>>
> mezzanine functions that I outlined, nor the hacks
> involving changes to the specs that Ladislav mentioned.
The current spec doesn't directly address this issue, but
essentially the idea is that modules will provide secure
execution environments. It's a deep question, and one that
the final design will address. I'm looking forward to the
"answer" myself.
> The problem with the current module spec is that once you
> make a function visible inside a module so that it can be
> used there, that function can be modified.
Maybe, and maybe not... :-)
> Don't misunderstand, I'm as much a fan of self-modifying
> code as the next mad scientist - it's just that I'm willing
> to give up modifiable functions for security reasons. We
> should be able to get by with replaceable functions, since
> we can easily track assignment if we want to. If we still
> need self-modifying code we can still do blocks.
Insightful observations, Brian.
> >Besides, only good hackers use REBOL! ;-) Why would
> >someone be so evil as to make good little REBOL do
> >something bad?! (-;
>
> A jealous Perl enthusiast, perhaps? :-)
Ditto. (-:
-jeff
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted